ditto icon indicating copy to clipboard operation
ditto copied to clipboard

Ditto SDK enhancements

Open w4tsn opened this issue 5 years ago • 0 comments

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!

w4tsn avatar Nov 24 '20 14:11 w4tsn