Re: Representative sample of industry protocols

On 25 October 2016 at 17:42, Kovatsch, Matthias <
matthias.kovatsch@siemens.com> wrote:

> When a protocol becomes important enough and fulfills some requirements,
> it is possible to define new URI schemes for those. For “minority
> protocols” a gateway approach is more viable. Depending on the scenario,
> however, people might translate to CoAP, for instance, rather than HTTP.
>
Even if it was possible to add URIs to all of the existing protocols
someone has decided are "important enough" and push that through all the
relevant standards bodies, how does that actually help? Ultimately it's
very unlikely every web browser is going to speak all of these new
protocols you're giving URIs to. At some point someone's going to want to
build a front end on top of these APIs and that's probably going to need to
talk HTTP using XHR/fetch because they are the tools available to web apps.

> For the same reasons that HTML supported many other apps: the IoT is in a
> different evolutionary state than the Web as we know it today. Back then,
> nobody knew which bits would survive. The same natural selection needs to
> happen for IoT approaches. But for now, the best solution to counter
> fragmentation is to accept it and provide means to resolve it.
>
I agree we should accept the diverse set of IoT protocols, but I disagree
on the means to resolve it. Rather than try to somehow force all of those
IoT protocols to adopt URIs and create standardised bindings for every
protocol following a common interface and data model I would argue for
using HTTP as a unifying application layer protocol on top, just as HTTP is
the web's application layer on top of the many network protocols that make
up the Internet.

>
>
> You would do it by mapping the ZigBee protocol to the WoT interaction
> model (Properties, Actions, Events) and convert the semantic information
> from the ZCL to the semantic TD annotations for the respective interactions.
>
>
>
> Now you already achieved one thing: You can write application code against
> the Scripting API that can interact with all the ZigBee devices around you.
>
>
>
> What we primarily wanted to achieve is that those devices become available
> outside ZigBee. Since there is also a mapping of the WoT interaction model
> to HTTP or CoAP or foo it is now trivial to connect them. Writing a gateway
> is not that much engineering work anymore that you have to for ZigBee and
> with another team for Z-Wave again ;)
>

I'm struggling to understand how this would actually work in practice so
please help me to understand.

So first you create a new version of ZigBee that provides zigbee:// URIs
and get all the device manufacturers to adopt this new version of the
standard. Then you create a ZigBee specific mapping of the Properties,
Actions and Events concepts using this new URI scheme. What have you
gained? You still can't use the same code to talk to a zigbee:// URI and a
coap:// URI so how have you improved interoperability? It's not even
backwards compatible with the old version of ZigBee.

Also trying to create a consistent scripting API you can use from any
language with any protocol doesn't sound feasible. Why not just create one
consistent REST API as a layer of abstraction on top of all the underlying
IoT protocols? You don't even need to define a new scripting API.


>
> In addition, the odd looking step above to connect the WoT interaction
> model to ZigBee only is quite important for thing companies. In WoT we do
> not simply ignore how the embedded IoT are implemented by letting the Web
> begin after the gateway. For me it is the Web of Things because we adapt
> patterns from the Web and apply Web technology to the IoT space: we push
> the Web programming model down to the embedded devices.
>

Ignoring the low level implementation details of the dozens of IoT
protocols is exactly what application developers should be able to do.
Trying to force web technologies further down the stack is not a good idea,
there's probably a reason a lot of these different networking protocols
exist, they are often optimised to solve specific classes of problems.


> This way you can write IoT app for a specific purpose without the need to
> care about the platform where it will run (similar to the situation we have
> now among the modern Web browsers and the apps they run).
>

The reason you can do that today is because the web standardised on HTTP,
HTML, CSS and JavaScript. Not because you can serve HTML over gopher:// and
script the DOM with Perl. Why not build on that by extending the web of
pages into a Web of Things using very established methods for building APIs
using HTTP and JSON which web applications can talk to. Out in the real
world this is already becoming the de-facto standard in most IoT platforms
anyway.

Ben