6.3 WoT servient on Smartphone - Browser as Servient

[mkovatsc]

The idea behind Figure 15 should be discussed and and explained much more. I guess having WoT client functionality in the browser is quite straight-forward. However, the rather big aspect of implementing "System Things" and having hardware drivers etc. in Web browsers might be seen critical.

I guess we need to build a careful case that references the existing APIs about location, camera, etc. and visions such as the Web Bluetooth CG.

Best also add such an editor's comment box to ask for feedback.

[mmccool]

The document as written does not have a problem with such things since it assumes local APIs can be used to access local hardware, rather than "System Things". I know we had a consensus to always talk to local devices via System Things but I'm wondering how practical it is to insist on this: people will want to access the WoT through a library and mix it in with other APIs, it's just natural. Maybe there should be a concept of a "Strict WoT Runtime" that only allows the use of WoT Client APIs. At any rate the current architecture document does not insist on the use of System Things.

I my edits I listed both "proprietary APIs" and " non-WoT APIs" as options as well as "System Things".

We could take care of this with a set of definitions. As it is we are missing "WoT Runtime" from the list of definitions, but I while we are at it we could add a "WoT Strict Runtime" definition that is intended to enforce the use of WoT Client/Server APIs for all external access.

[zolkis]

Defining "strict" on WoT Runtime makes sense from security point of view for standalone runtimes.

In browsers, we should adhere to the browser runtime environment. We definitely want to avoid providing a mechanism that can be used to invoke any other API from a "blank checque" WoT API accessing system things.

To simplify/unify, we need to re-evaluate runtime issues out of the box.

[mkovatsc]

I am not sure where this discussion was taken...

The original point was that Section 6.3 assumes a Web browser implementing WoT without any details given on what that means. In particular for browser vendors, we have to define more clearly what we would assume under "a Web browser implementing WoT" and be clear about what this entails. A Web browser is a quite well-defined piece of software, while a WoT Servient has way more freedom beyond the Scripting API -- simply because we do not have much deployment experience yet.

To the new topics:

Not sure why implementing random APIs for the runtime was brought back on the table. We cannot prevent anyone from doing it, but it will not be standards compliant and script portability would be killed.

Every W3C WoT runtime must be a "strict" runtime. Whoever is putting more APIs in, is reenacting the browser wars.

[zolkis]

Web browser implementing WoT without any details given on what that means.

Right, actually this may need a very concise separate W3C specification. For time being (FPWD) we can keep it in the Scripting API doc.

Every W3C WoT runtime must be a "strict" runtime.

Right. My point is that strict-ness should be defined not only as limiting the API to ConsumedThing, but also by how to deploy and control System Thing drivers/modules (or more exactly, how NOT to do it :).

[mkovatsc]

I created #25 to have a more specific issue for the Architecture document (WoT on top of existing browser API).

The strict-ness should be explained in the Scripting API document.

Closing this one.