Enhancements for Device Services

Implement dynamic discovery using Provision Watchers
REST request/response types to be refined as necessary in line with the v2 rework in the core
Provide clean API for query parameters
- Currently passing entire query string as an extra Attribute
Make more configuration dynamic (ideally, all of it)
- Including the driver-specific configuration
Implement command chaining (deviceCommand contains other deviceCommands)
Allow driver to manage device operational state
Allow driver to feed back meaningful error information (not just ok/fail) from get/set handlers
Implement minimum/maximum restrictions on actuation parameters

Testing

Build-out of blackbox test suite
Define process for self-certification of device services
- Currently estimated (For Fuji version) N.E.T. January 2020, but any Fuji slippage will push this back

Remove legacy fields in metadata
- ProvisionWatcher: OperatingState
- PropertyValue: Precision, Size
- ResourceOperation: Resource, Object
- ProfileProperty: Units becomes String
Reduce boilerplate in coreCommands
- All it really needs for each command is the name and whether it's get, set, or both?
Readings will need to contain type information (ValueDescriptors are going away)
~~Add field in Event to store query parameters that were used when it was generated~~
- No, we don't support use of QPs to hold extra addressing information

For autonomous and REST-driven data, we can feed back errors to the caller, eg 503 unavailable.

For AutoEvents we could apply a scaling factor to the intervals?

Monitor the number of simultaneous calls to get/put handlers?

Serialize Event submission and monitor the queue length?

Compare time taken to process an AutoEvent with its specified interval?