Open mkovatsc opened 7 years ago
In respect to the examples: XMLHttpRequest object and WebSockets API, please add Server-Sent Events and the use of WebRTC for peer to peer data exchange.
Arch call on 13.2.: Defer until we reviewed the browser section of the architecture document
The previous section "6.6 WoT in the Web Browser" will be restored and put into the "snippet section" Snippet section will be moved to an annex for now and removed at a later cleanup, after useful parts have been added to previous chapters.
TPAC discussion:
Architecture call on 13.2.: We can aim for JavaScript library using the fetch API or a WebAssembly solution. We can even run node-WoT in the browser, we demoed it. https://github.com/eclipse/thingweb.node-wot#as-a-browser-library
Native integration into browser is currently out of scope, since it would require implementing various protocols in the browser. No concrete use case for exposing things yet, for consumers we can consider sensor fusion/mashup. This use case is already covered.
No concrete use case for exposing things yet
Might be far fetched but there can be a use case where the Things consumed by the browser can be used to create an Exposed Thing. For example, after consuming 4 temperature sensors, one can create an average temperature exposing Thing. Quite probably not useful for more than demo purposes?
after consuming 4 temperature sensors, one can create an average temperature exposing Thing
This has been mentioned in the call, but it's still a theoretical use case. Also, when someone exposed Things, there are scalability and lifecycle considerations, probably one doesn't want to serve ExposedThings for long time from a browser run in a laptop or phone.
There are some ideas of using web workers for doing that, but so far one could use node-wot to serve Things over HTTP / WSS.
Ideally we would have a non-technical motivation for this use case, i.e. a scenario that adds value for a specific application domain.
2nd architecture call on Feb 13th: This may be related to service workers, we should think about separating physical device (hardware) and Web browser (software stack). An embedded browser could include a servient and offer bidirectional scenarios. Devices can be smart hubs.
w3c/wot-architecture#15 raised the issue to be more clear about what it means to implement WoT in the Web browser. I propose a new section for this, which (for now) explains how a JS library can provide the Scripting API on top of the existing browser APIs (e.g., XMLHttpRequest object or WebSockets API).
Later versions of the document could sketch how a more native integration would look like.