Re: Seeking WebSocket proposal team

> On 24 Oct 2016, at 09:02, Robert Gallas <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>>