Ditto SDK enhancements
Since live commands are implemented on devices the ditto SDK (Java AND JavaScript, capital 'and' since I fear the latter is a bit under-developed feature wise :sweat_smile:) needs to provide as much guidance / abstraction as possible to ease the agent implementation. Some initial thoughts on this:
- if a command is not yet implemented for a feature on the live channel a 400 with an "unimplemented" notice should be returned. 400, because I don't know if there's any better suited status. 406 sound similar, but is semantically different.
- implementing the commands needs an API to 'plug-in' implementations
- for AMQP and MQTT connected clients I suppose (at least for mqtt) that the client will need an implementation to interact with an mqtt / amqp client ? As additional data channel to websocket and REST
My basic idea here is to have as much of the API as possible defined as ditto protocol for commands, such that I don't need to worry much about status codes and such. Opposed to the messages API where implementation is highly use-case and device specific, which is good since e.g. (vorto) operations implemented as messages follow a custom API.
A bit of background where I'm coming from with this: I'm implementing python and js agents for IoT devices. There is also a node-red project, where the js client will receive a node-red contrib wrapper node to allow graphical interaction with ditto in node-red.
I'll additionally require a python SDK for some devices which I plan to open-source / contribute.
This will probably end up in multiple issues I suppose - let's discuss!