AW: Seeking WebSocket proposal team

Dave, you basically restated the overall goals of the WoT Working Group:


-        Define a narrow-waist model for interaction and metadata that can bridge between existing platforms.

-        On top we have a common Scripting API to build applications based on the narrow-waist model

-        Below we have protocol mapping descriptions that inform how the interactions are mapped to concrete messages of different protocols including protocol dialects (e.g., OCF-style CoAP vs OneM2M-style CoAP).

In this thread, I would like to come back to the concrete usage of WebSockets for WoT (in respect of the above goals):
Which platforms actually use WebSockets for communication?
How do people communicate over WebSockets? Is it a random protocol invented to connect two parts of the same application or is there something that can actually span multiple applications, vendors, and domains?

Kind regards
Matthias


Von: Dave Raggett [mailto:dsr@w3.org]
Gesendet: Montag, 24. Oktober 2016 11:49
An: Robert Gallas
Cc: MEDINI LIONEL; Kovatsch, Matthias (CT RDA NEC EMB-DE); bergi; public-wot-ig
Betreff: Re: Seeking WebSocket proposal team


On 24 Oct 2016, at 09:02, Robert Gallas <gallas.robert@gmail.com<mailto:gallas.robert@gmail.com>> wrote:

Hi all,

For me more interesting topic than specific protocol binding, would be talk about separation of transport protocol from on wire data format/command-message/.

Having common, transport protocol agnostic data format, would simplify subsequend protocol binding and would be more intuitive to developers when switching between different transport protocols. Even REST is command type transport with trasport specific command-message structure.

Rather than asking if there is need for WebSocket binding I'd like to ask how to structure message format to be able to map it on virtualy any transport protocol. Transport protocols come and go based on various real life constraints. Security considerations, HW efficiency, industry standards, etc. I'm afraid that if there will be no common message format someone will have to always reinvent the wheel when designing transport protocol specific bindings.

With great oversimplification in mind, message format with operation (get, set, invoke, subscribe), target (/throtle-move), value (20) could be sent by HTTP, MQTT, AMQP, WS etc. Platform implementors would just need to add thin layer of transport protocol adapters to pack and unpack common command messages.

But this is probably selfcontained topic.

Best Regards
Robert

A related approach is to consider the requirements for a abstract messaging layer that can be bound to specific protocols and communication patterns.  The requirements across different application domains vary enormously, so we should expect to support a range of different protocols and communication patterns.

For example, on the factory floor there may be stringent real-time requirements.  For some cases, it may be okay to drop the occasional data point, whilst for other cases it may be critically important to keep a complete history (for black boxes, legal liability, etc.). We can have peer to peer frameworks, as for sensor networks, or centralised approaches where data is processed at the network edge and funnelled to the cloud. Further considerations include the need for multiplexing multiple data sources into a single stream and buffering for improved battery life or network efficiency. We also need to support ambient powered devices that perforce sleep most of the time.

By thinking about an abstract messaging layer, we can provide a clean interface between the different layers in the communication stack. This allows us to decouple the data formats used at the application layer from the data forms used by the communication technologies at lower layers.

My suggestion would be to form a sub group that are interested in collecting use cases and requirements, and exploring a broad range of communication patterns as listed above, along with practical demonstrations in running code.

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