AW: Seeking WebSocket proposal team

Hello Robert,

I like your raised  points and would like to add my two cents:

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

Totally agree here. For interop, I see it important to abstract details of existing solutions rather than starting with a new solution.

It is of course an impulse of every developer to go "n+1" and come up with a new, "simple" protocol on top of WS, however, the debate is very valid if its not wiser to take one of the existing protocols that can transparently be used outside of the WS as well.
 
> 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.

What you describe her is my understanding of our discussion in the topic of "protocol bindings" so far.
Find a set of abstractions, a "narrow waist" - of information that need to be in the message and simplify wherever possible.
Its far from coincidence that we saw resources with an uri and a state (can be as simple as a value) and a handful of operations (red, write, invoke, subscribe, unlink) as a dominant pattern.
This can then directly be mapped to concrete messages such as HTTP or CoAP requests and responses and also allows us to easily map to anything remotely RESTful (e.g. even BLE GATT or XMPP) and built very thin shim-layers for other protocols (such as e.g. MQTT).

Yes, you cannot directly interact with them from a browser in many cases - but there are cases such as thing-to-thing interaction, backend and thing interaction where this is not a requirement.
Websockets can however be useful to create a transport that is usable out of the browser and speak one of the mentioned transfer-layer protocols above that transport  -see the discussion around CoAP over Websockets or MQTT over websockets.

Best regards,
Johannes

Received on Monday, 24 October 2016 09:46:25 UTC