Separate ExposedThing API

[zolkis]

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).

[zolkis]

Along similar lines, we could have examples on how to use already standard APIs to implement for instance consuming Things (e.g. using the Fetch API alone).

Of course, the Scripting API standardizes some of the things defined in the TD spec, so not every app has to redo the same, for instance handling content types and data schemas for the values accessed. Even though separate 3rd party libraries might be able to to that, too.

So it would be nice to show side-by-side examples of using the WoT Scripting API along with standard browser APIs like Fetch, for consuming and using Things.

[relu91]

I agree that the scope of the ExposeThing API is different from the other use-cases. In particular, I like this statement:

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.

About #299 do you think that just clarifying this separation would help implementers in the process of exposing a Thing? Should we need more functions to have a standard sandboxed environment? Or at least define some requirements?

[zolkis]

About #299

Replied there. :)

[relu91]

Keeping issues linked: #298

[danielpeintner]

Scripting API Call 2021-08-30

• @zolkis check whether all aspects are integrated and what is missing
• split work in several documents?
• rename issue?