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

Re: Regular Web of Things call on scripting API

From: Dave Raggett <dsr@w3.org>
Date: Wed, 2 Nov 2016 11:04:30 +0000
Cc: "Hund, Johannes" <johannes.hund@siemens.com>, "public-wot-ig@w3.org" <public-wot-ig@w3.org>
Message-Id: <56215A10-0C20-4A50-9246-1D2F8F64DE9A@w3.org>
To: Benjamin Francis <bfrancis@mozilla.com>

> On 1 Nov 2016, at 19:19, Benjamin Francis <bfrancis@mozilla.com> wrote:
> On 1 November 2016 at 14:31, Dave Raggett <dsr@w3.org <mailto:dsr@w3.org>> wrote:
> How would your proposal decouple application scripts from the platform’s choice of protocols, given that REST and HTTP isn’t always appropriate?
> My view is that the Web of Things should be built on URLs and HTTP rather than trying to be entirely application protocol-agnostic (which I don't think is realistic or even technically possible). That's what makes it the Web of Things as opposed to the Internet of Things.

You’re welcome to that opinion. For me, the Web in the Web of things is about employing the core Web architecture:

  1.  a means for addressing things
  2.  machine interpretable descriptions of things and their relationships (i.e. links, forming a web)
  3.  a suite of protocols for accessing things and their descriptions

There are already many IoT platforms and protocols, and defining one more competing platform won’t really help with addressing the fragmentation into an archipelago of incompatible solutions.  This is why it makes sense to learn from the success of the Internet as a means to enable end to end messaging across different network technologies. We need to define an abstraction layer that complements  rather than competes with the range of IoT platforms and protocols. I expect that HTTP will play an important role, but don’t see the benefit of excluding other protocols, and forcing them to the network edge as it were.

The vision of the Web of things as an abstraction layer is future proof in that it will scale to new requirements as different groups of people apply it to widely different application domains. For example, cyber-physical systems may impose real-time requirements for which HTTP is a poor fit. In other cases involving data streaming, where the loss of the occasional data point isn’t critical, then UDP based protocols may make the most sense.

So to move forward, can we agree to support HTTP, but not to rule out other protocols where those are needed to address requirements for which HTTP is a poor fit?

   Dave Raggett <dsr@w3.org <mailto:dsr@w3.org>>

Received on Wednesday, 2 November 2016 11:04:47 UTC

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