Re: Seeking WebSocket proposal team

Johannes, Dave ... correct

On Mon, Oct 24, 2016 at 11:48 AM, Dave Raggett <dsr@w3.org> wrote:

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