Re: Representative sample of industry protocols

Hi Johannes,

On 25 October 2016 at 21:20, Hund, Johannes <johannes.hund@siemens.com>
wrote:

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

Can you explain this type of use case in a bit more detail? Why is multiple
WoT protocols better than one WoT protocol in the case of Thing to Thing
communication? Bear in mind that the WoT API could exist on the Thing
itself, on a gateway or in the cloud. With the latter two patterns the
Thing itself can use whatever protocol it wants but the web layer allows
Things to talk to each other using a common protocol.

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

How would you use URIs and a request/response pattern with payloads and
response codes with protocols like X10
<https://en.wikipedia.org/wiki/X10_(industry_standard)> and CAN bus
<https://en.wikipedia.org/wiki/CAN_bus> (from the list above)? It doesn't
even sound technically possible.


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

Why do you need a scripting API to talk to a Thing? Why can't you just have
an app communicate with it over the WoT API? Pretty much any programming
language or application framework can call a REST API.


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

If they just need to talk to a consistent HTTP REST API following the WoT
model then they just need one implementation. If they need to be able to
talk all of the potential WoT protocols above, then 74. I think I must be
missing your point?

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

But now the web exists. So why not use it?

The thing that's great about HTTP isn't that it's a good technical solution
to every problem, I'm not sure HTTP is the best technical solution to any
problem! The great thing about HTTP is that it's ubiquitous, which makes it
a good solution to interoperability problems.

Ben