Open zolkis opened 3 years ago
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.
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?
Keeping issues linked: #298
Scripting API Call 2021-08-30
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:
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:
In the latter case, there are some issues:
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).