Can an Exposed Thing provide a Protocol Binding?

[mmccool]

In a consumed thing, the runtime hides the protocol binding. But when creating an exposed thing, the Protocol Binding information needs to be specified via the Scripting API.

[zolkis]

The expose() method takes a ThingInit dictionary that has a description property for TD. To my current understanding, the Bindings information could be part of that TD. Or should we have an explicit other property for bindings description?

[mkovatsc]

So far, the assumption was that the application developer should not need to care about the protocol aspects. It depends on the Servient executing the script, on which bindings the Thing will be exposes -- the ones the Servient supports.

To build a sensible application, someone of course needs to take care that the right Servient with the right Bindings is provided. Similarly, someone has to take care that a Web app becomes available on the correct vhost, interface, etc.

Thus, I would leave this out of scope for now. A ManagerThing could again have some means to do fine-tuning, but we should not distract ourselves with the details at this point in time. With the ThingInit, we also already have an extension point in place...

I would even propose to close this issue.

[Kazuo-Kajimoto]

@mkovatsc +1

[zolkis]

So far, the assumption was that the application developer should not need to care about the protocol aspects.

In theory we can abstract everything, it practice an app needs to configure the underlying protocol stacks. You can say it's out of scope, but then we don't help much app developers in their real problems.

[mkovatsc]

The Scripting API should be something simple to be productive swiftly. I see more a PHP than a Jetty. developers should not be forced to understand all the details at once through one huge spec. We will not even understand what configuration possibilities we will need until end of next year. So better put this configuration outside the Scripting API. Maybe we can have a generic call to a config registry like a better version of PHP's "set_ini()".

[zolkis]

Productive means it produces working solutions.... without gaining experience with full stack implementations it is guaranteed we will misdesign APIs...

I would start with existing IoT APIs with which we already have experience, then see what we can do better with WoT concepts, and build up from there.

With the FPWD version of the API we could already implement CRUDN style bindings if the app code has access to the libraries that implement connectivity (e.g. CoAP/HTTP).

The next level is to generalize this implementation with the help of protocol bindings, and generate part of the boilerplate with the help of information coming from a Protocol Binding description.

The next level is to generalize this even further with the help of TD (also containing Protocol Binding description). It means the current ExposedThing API will be simplified:

• create from TD, i.e. generate properties, actions, events, and then
• bind app defined request handlers to these (the onXxx() methods).

But until then I'd support something really simple like what Dave proposed in #64.

[zolkis]

Let's postpone this discussion until Protocol Binding implementations are in place and we can figure out how to handle its descriptions in the best way. Leaving the issue open.

[zolkis]

In the current version one can specify request handlers in ExposedThing, for property read/write and action invocation. So a script can theoretically provide protocol bindings in these handler methods. However, we don't have that possibility for Events (the ExposedThing does not define a callback for what to do when an Event subscription request is received from a client): implementations encapsulate that.