W3C home > Mailing lists > Public > public-wot-ig@w3.org > November 2016

Re: Regular Web of Things call on scripting API

From: David Janes <davidjanes@davidjanes.com>
Date: Tue, 8 Nov 2016 15:22:22 -0500
Message-ID: <CACp1KyOOY7pQwA1SifFLw-mf8dOZSxBp02Hb9B6YCFPt_PqAFg@mail.gmail.com>
To: Benjamin Francis <bfrancis@mozilla.com>
Cc: "Hund, Johannes" <johannes.hund@siemens.com>, "Kis, Zoltan" <zoltan.kis@intel.com>, Dave Raggett <dsr@w3.org>, "public-wot-ig@w3.org" <public-wot-ig@w3.org>
Though I agree that defining a programming interface is not a good starting
point, it seems to me a good REST interface (to a strong degree) will "fall
out" of a properly defined and well-thought-out Thing Description.


On Tue, Nov 8, 2016 at 11:16 AM, Benjamin Francis <bfrancis@mozilla.com>

> 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
Received on Tuesday, 8 November 2016 20:23:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:27:08 UTC