Potential scope for enhancements / changes in Ireland/v2.0 cycle

  • Consume v2 API
    • At Hanoi, the v2 REST interfaces for core-data and core-metadata should be available - use them.
    • Unconditionally or should this be a config option?
  • Old items on-hold because they are breaking changes
    • support-logging removal
    • Naming scheme changes for config.Clients
  • Event filtering: implementation
    • Requires 1) design phase completed 2) volunteer effort for implementation
  • Messagebus for Device Service → App Service: implementation
  • Obtain security credentials from secret store: provision in the SDKs, implement at least in device-mqtt
    • Stretch: other DSs
  • Remove binary representation (base64) for floating point values
  • Remove OperationalState for device services (as opposed to for individual devices)
  • Rename OperationalState values (currently ENABLED/DISABLED, suggest UP/DOWN)
  • Ensure that the various agreed device profile changes are in for V2: Currently in place in go-mod-core-contracts
    • Units simplification
    • CoreCommands simplification
    • Removal of deprecated PropertyValue fields: precision, size
  • No labels

5 Comments

  1. Jim White

    Message bus from DS to AS if not completed in Hanoi.
    Check of requests against a device service against profiles (setting above, min, max, etc.)?
    Max request size check as discussed this release but I think deferred for implementation until Ireland?

  2. Jim White

    Per DS meeting - vault credentials for both SDKs

  3. Tony Espy

    • Messagebus for Device Service → Core Data: implementation
      • Shouldn't this be device service → application services? This is the first I've heard of using a message bus for DS to CD.
    • The last two bullets seems to conflict, one says remove OperationalState, and the second says re-name its values?
    • Remove binary representation (base64) for floating point values
      • This will also require some work in go-mod-core-contracts, Core Data, and Core Metadata.
    • security credentials from vault
      • We should also include the revamp of device-mqtt to be at parity with app-service-configurable with respect to MQTT security options. Yes, there might be other device services that may want to secure secrets in Vault, but I don't think we can wait another year to bring device-mqtt up to parity with ASC.
    • Also something seems to have dropped off the radar is re-vamping the units in device profiles. Currently we still have this 'units: { type: "String", readWrite: "R", defaultValue: "" }', there'd been talk awhile back of just making this a simple string. Another thought would be to investigate whether there are any existing standards for describing units of measurement with an towards making them machine readable (vs. a string).
    • A couple of other device profile cleanups:
      • Both units and values have a ReadWrite property, but as far as I can tell, there's no enforcement of these fields.
      • PropertyValue still includes Precision and Size attributes, neither of which I think have ever been used (at least in the Go SDK).


  4. Tony Espy

    Also one other device profile tweak that I'd been thinking about for awhile is getting rid of the coreCommands section of the device profile. In theory, it should be possible for the SDKs to auto-generate this information required to populate the commands in Core Metadata. The return codes are the same for all commands (i.e. they never change), and it should be possible to determine the parameter names automatically. Likewise the descriptions are all boiler plate other than the actual name of the deviceResource(s) being read/written.

  5. Tony Espy

    One other device profile related item. In our discussions about the LLRP/RFID service we talked a bit about whether device resources could by dynamically added to device profiles and whether the device service would pickup these up at runtime (pretty sure the answer was no). It was also mentioned that removing device resources shouldn't be allowed if readings had already been produced that reference the device resources. Should Core Metadata guard against this (i.e. don't let device resources be changed/deleted via an update)?