Re: Regular Web of Things call on scripting API

On 8 November 2016 at 08:41, Hund, Johannes <johannes.hund@siemens.com>
wrote:

> - the remote access is described by the thing description which tells you
> how the REST API works in CRUDN primitives
>
> - the protocol bindings define how to express the primitives in a protocol
>
> - the local access is done via the scripting API. This allows us as well
> to reuse the accessing side (client side) of this API for a script-level
> access to remote access.
>

I'd suggest that a language-agnostic local scripting API for programming
connected devices has nothing to do with the web and therefore would be an
odd topic for a W3C specification. Being able to re-use the same scripting
API on the client side and the server side is a novel idea, but doesn't
seem particularly important in practice.

The way to connect devices to the web is to give them URLs. In my opinion
defining a data model for describing Things on the web and a common web
based interface for interacting with them are fundamental to extending the
web of pages into a web of things.


> The delta between the existing approaches e.g. from OCF and EVERYTHNG and
> the current discussion that is based on those is IMO mainly which part is
> explicitly stated, which part is "well-known", and how far we go with
> standardizing vs. leaving it open for implementers
>

Another example of this is Google Weave which (without giving too much
away) defines a REST API and then provides helper libraries (e.g. for
Android and iOS) to call that API. Anyone can create a helper library to
call a REST API using their language of choice.

The Connected Devices team at Mozilla was previously the Firefox OS team
who built a browser-based operating system which shipped on around 15
smartphone products in 30 countries. Over the past five years we designed
around 30 new device APIs which exposed various hardware features to
applications using web technologies, and tried to standardise those APIs
through the W3C. This has taught us a few things about what works well, and
what doesn't.

If there's one takeaway for me from this experience it's that in many cases
we picked the wrong part of the web stack to build those APIs. When you
have a browser engine every problem looks like a DOM API. If we built
Firefox OS again today we would implement the hardware APIs as web services
on the server side of the web stack which web applications can interact
with via a REST interface. Not as JavaScript APIs.

It's with this experience in mind that I again strongly recommend that this
group focus on defining the Thing Description for describing Things and a
simple web services based programming interface to interact with them.
Helper libraries to call this service may well be useful, but that is the
wrong part of the web stack at which to try to standardise this type of
interface.

Ben