Description
Separating the ExposedThing API to its own API entry point has been discussed several times in the WoT WG.
Recently, we have separated ConsumedThing and ExposedThing objects (the latter no longer implements the former by default), due to misunderstanding.
I think we have further misunderstandings to clear about ExposedThing use cases, permissions, provisioning needs, etc.
The different permissions alone would warrant a separate API for ExposedThing.
Currently the WoT Scripting API spec has 3 conformance classes:
- discovery
- consume Things
- produce exposed Things.
Out of these, the use cases for discovery and consuming Things is clear, they are client interfaces and are standardized in WoT WG (architecture, Thing Description, discovery etc). For exposed Things, the TD spec does not provide any standard on how to generate the TDs. It just describes what to expect from a TD from a consuming side.
So both the use cases and implementations for exposed Things are more obscure:
- a WoT runtime exposes Things that are local to a device, or are nearby, reachable by a private link, or are remote but with privileged access
- a device maker could choose to just implement exposed Things natively, and SW updates and provisioning happen in the specific way the platform is built
- scripting might make easier to expose Things in systems that host a WoT runtime, i.e. there is an abstract interface that makes easier to write WoT runtimes for OEMs that host ExposedThings.
In the latter case, there are some issues:
- exposing Things requires access to system libraries (that implement e.g. GPIO, PWM, Bluetooth in order to expose sensors, and perhaps also to comms libraries like HTTP, CoAP, MQTT etc).
- some of the heavy lifting could be done by a library like node-wot, for convenience, but then it is tied together with consuming and discovery
- provisioning and configuration has been out of scope in the previous charter but has to play along with the given hosting platform
- in addition to host platform's SW update, provisioning and lifecycle in general, there might be in the future WoT requirements on provisioning, SW update etc.
In this respect, providing an ExposedThing API is similar class (from the point of view of permissions, dependencies, provisioning etc) as providing a WoT discovery server (Thing directory). It is a system level convenience API, not a client API.
Even if there is a sandboxing environment behind it, handling it together with consume and discover is a mistake IMHO. Sandboxing just regroups the dependencies and changes the way to access the same system APIs, in either way these permissions should be grouped separately between consuming/discovery and exposing Things.
In summary, I think there would be more clarity if ExposedThing had a separate [specification and] implementation (meaning different package with different dependencies). Of course, any given implementation could choose to implement all 3 conformance classes, but preferably would do so in different packages.
I suggest this topic is also discussed with the whole WG (architecture, TD, discovery, task forces).