Re: Regular Web of Things call on scripting API

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.

D.

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

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