AW: Representative sample of industry protocols

Dear Ben, 

Disclaimer: I drop my personal two cents here again.

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

I totally understand your point, however I sense there is a bit a disconnect about the scope of use cases we want to address.

An important case we see is to ease application development not only for a browser interacting with a thing, but actually also for a thing (a gateway) interacting with another thing.

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

I do not think the difference and success of HTTP was using readable strings (which is a problem on microcontrollers), but rather the very restricted and reduced complexity. 

What we did pinpoint is REST as the "narrow waist" that you refer to with HTTP. 
This allows us to take the concepts that make up HTTP and apply them to any transfer.

A request, a response, a handful of verbs, and uri, headers, payloads, response codes. When you can express that, you can map it to HTTP - or generally to REST.

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

A web browser is a successful piece of software because many people write software for it, and because if I write a piece of js, I do not care which browser runs it.
Nowerdays.
Remember "best viewed with"? Luckily since "Web 2.0" was a hip term we look at those icons on wayback machine.
We try to expand the successful elements that ignited  web evolution and bring it to the heavy fragmentation of the IoT.

I.e. define a narrow waist of scripting APIs that enable devs to write code or even applications that can run on various devices.

Or as an example:
If Amazon/Alibaba/somebody would write the infamous app for a fridge that tracks and reorders food, would they have to write it 10 times, one time for each vendor?
 
> 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.

I remember web pages consisting of lots of ftp:// links and even things like "WAP", flash, java applets and silverlight. 
(Please trust me, that I am totally not trying to advocate those here!)

I agree that in the end there will be dominant survivors and it might even be a single one (there I have my doubts) - maybe the current one.
However, I do not think the web would have evolved to its current state if it was not extensible.

I had this slide "Tim Berners Lee did not have cat videos in mind" - the web of pages was designed for academic papers. 
The evolution leading to Youtube, google maps etc. did work because it was extensible beyond the scope it was thought for.

The web is the "narrow waist" that people could agree on, but people were always able to extend and innovate.

Best regards,
Johannes

Received on Tuesday, 25 October 2016 20:21:03 UTC