Re: Project Things by Mozilla and the Web Thing API

Hi Zoltan,

On 13 July 2017 at 11:10, Kis, Zoltan <zoltan.kis@intel.com> wrote:

>
> I agree with the goal of making TDs more Web-developer friendly, with core
> vocabulary and then extensions.
>

Great. To contribute to that discussion I've filed an issue on GitHub
<https://github.com/w3c/wot-thing-description/issues/12> proposing
"properties", "actions" and "events" members at the top level of the Thing
Description.

Also, the gateway concept looks sound. However, I'd be interested in how
> far can we go with protocol bindings. Packaged SW update is less of an
> issue for a gateway, but it's probably more difficult for an end device
> that needs re-flashing and it's already deployed.
>

I'm not sure I understand what you mean. What's the link between protocol
bindings and over the air updates that you're making?


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

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.

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.



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

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'm sorry for all the basic questions but I'm still struggling to get my
head around the vision of the Web of Things described in the current
working group charter and the documents currently being produced. As a web
developer it doesn't sound like anything I recognise as the web.

Ben