You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 😅) 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!
The text was updated successfully, but these errors were encountered:
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 😅) needs to provide as much guidance / abstraction as possible to ease the agent implementation. Some initial thoughts on this:
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!
The text was updated successfully, but these errors were encountered: