Re: Project Things by Mozilla and the Web Thing API

Hi Ben,

On Thu, Jul 13, 2017 at 9:49 PM, Benjamin Francis <bfrancis@mozilla.com>
wrote:
>
>
>
>> Scripting is an optional building block for WoT, and IMHO it's not in
>> conflict with your goals about web interfaces and SW libraries. You could
>> consider it as an example, rather than _the_ way to do Things.
>>
>
> I agree that it isn't in conflict, but if it's not intended to become a
> W3C recommendation of _the_ way to do Things then why does it need to be a
> W3C specification at all? Why not just implement pieces of software as
> demonstrators of how a scripting runtime could be created to talk to web
> things.
>
> Implementations may differ, but the use cases and context stay the same. Therefore,
>> IMHO it still makes sense to standardize a WoT Scripting API for
>> JavaScript/TypeScript. They do work against a web interface (the WoT
>> interface).
>>
>
> It's interesting that you describe it as standardizing a scripting API for
> JavaScript/TypeScript, because the charter
> <https://www.w3.org/2016/12/wot-wg-2016.html> makes no mention of those
> languages and actually says "APIs will be defined in ways that are
> independent of the choice of programming languages". This is one of the
> points I felt was unrealistic.
>
>
Browsers may be WoT clients, but also WoT servers. In my understanding, W3C
standardization of the scripting API aims both the browser and runtime
implementations. At the moment the discussions are limited at runtime
level, but so far all the IG and WG participants (but Mozilla) have been
interested in standardizing a scripting interface.


> To be honest I still don't understand what the Scripting API actually is
> or what it has to do with the web. The web is made of resources linked by
> URLs, not function calls. All the terminology around runtimes and
> life-cycles reminds me a lot of the packaged app runtime
> <https://www.w3.org/TR/runtime/> the System Applications Working Group
> tried to create which also had nothing to do with the web and went nowhere.
>

Because it tried to impose a runtime inside the browser and went beyond the
browser security model. The WoT WG currently aims node.js type runtimes.
There is a definitely clear customer interest in this type of scripting.
However, as said it is optional, in order to please purist approaches.


>
> Who would implement a standard JavaScript/TypeScript API?
>
>    - Browsers vendors? Have any browser vendors expressed an interest in
>    this? Why can't web applications reference web things using URLs like any
>    other web resource and communicate with them over HTTP & WebSockets using
>    the DOM APIs that already exist?
>    - Server-side JavaScript implementations? Why can't web servers serve
>    Web Thing descriptions like any other web resource and host REST &
>    WebSocket APIs to communicate with them like any other web service? If HTTP
>    or HTTP/2 aren't fit for purpose for IoT use cases for some reason then
>    let's talk to the IETF and create an HTTP/3.
>
>
>

They do. One way to create TDs is by scripting, and one way to consume TDs
is by scripting. However, you as a client or server are not compelled to
use scripting.


> Also, it makes sense to work on and have examples on script deployment
>> (Manager Thing), related use cases, functionality, vocabulary etc
>>
>
> What is "script deployment"? What is a "manager thing"? I can't find these
> concepts defined anywhere.
>

It is work in progress, discussed in issues on the scripting repo. Again,
this was driven by customer use cases. However, instead of inventing a
separate interface for script management, we do it by the WoT interface,
i.e. devices that support this functionality, expose it via a Thing. A
special Thing at that, but still a Thing.


> Similarly, the WoT interface concepts can be applied to access to system
>> specific functionality. TD's can be defined for a wide range of
>> functionality.
>>
>> Security, privacy, access rights, policies, "manifests" (SW extensions),
>> etc are work in progress where Mozilla's input would be beneficial.
>>
>
> I'm happy to try to get Mozilla input on any open issues. I'm not sure
> what you mean by "manifests (SW extensions)" though.
>

I was referring to the  Web App Manifest with regards to script deployment.
https://w3c.github.io/manifest/

In summary, to stress my original point, I do share the points about
- TDs should be simple, with additional semantic extensions
- common WoT deployments will include a WoT gateway, and this will
influence a lot security and other problems to solve.
However, while I do appreciate you try to apply Occam's razor on WoT
approaches and principles, and I agree that should be done in order to set
priorities, some of the features that get criticized, like scripting,
and automatic interpretation of TDs are actually based on customer
requirements, so please allow the rest of us to work on them in this group
:).

Best regards,
Zoltan