White House & IOT, WOT

Hi All - 

Sorry that I have not contributed as I should. I'm likely to have someone else fill this role for TPG. 

Yesterday I attended a summit at the White House. Both US CTO Megan Smith and Sr. White House policy Director Tom Kalil spoke about the criticality of the IOT and Open Source to the Open Gov initiative. Of course, this was a special summit on Technology Inclusion for people with Disabilities. 

Seems to me that this needs to be further emphasized in the WOT. I plan to pursue this topic further with both Smith and Kalil. 

Here is the link to the stream: https://t.co/kqVLBcDnUk

Regards,

Mike

Mike Paciello
+1 603 566 7713
From My iPhone



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