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
- 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 simplificationCoreCommands simplificationRemoval of deprecated PropertyValue fields: precision, size
{"serverDuration": 166, "requestCorrelationId": "19e3204c3c3c0f18"}
5 Comments
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?
Jim White
Per DS meeting - vault credentials for both SDKs
Tony Espy
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.
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)?