Re: [hybi] Fwd: The MessageBroker WebSocket Subprotocol

[Bruce Atherton <[e-mail]>]

On 02/10/2011 5:45 PM, Greg Wilkins wrote:
> I do not think  opcodes are the right fit for defining messages in a
> subprotocol (at least not in the ws protocol as we have designed it).
>
> While I can imagine some subprotocols would desire to have opcode like
> metadata associated with a message, I  can also imagine many
> subprotocols will use JSON/XML as their message exchange format and
> thus will better use fields/elements/attributes to convey message
> type.

Exactly. Many subprotocols will not need anything more than the 
text/binary division we have. These subprotocols will not need any 
extension because they will not need new opcodes. Other subprotocols 
will contain the message type within the message themselves. HTTP 
requests are an example, as are SIP messages.

But then there are the ones where the type is not carried within the 
message. While you could define an extra header on the payload to carry 
that information, it seems like what the opcode is designed for. In 
fact, I can't think of any other use for the opcode than that. I could 
be wrong, perhaps it will turn out there are other uses for it. Time 
will tell once there are lots of implementations and deployments.

I am working on a Websocket-SIP bridge that uses different opcodes for 
SIP messages versus media channel messages. Now by happenstance I can 
send the SIP messages as text messages and media channel messages as 
binary (even if the media channel is a text one) and get the behaviour I 
want, but I would be lying to myself if I thought the opcodes still 
represented text and binary. I am overloading them to mean SIP and 
media. If I had needed more than 2 types of messages, or if I needed two 
types that were both binary, I would have had to define my own opcodes 
in an extension or prepend a header to get the behaviour I wanted.

MUX will be an example of a combination of subprotocol and extension 
assuming it ends up requiring new opcodes or flags. It defines a 
specific way for information to be passed over the Websocket transport 
making it a subprotocol that carries multiple channels, each potentially 
with its own subprotocol.

> Subprotocols are exposed to the application in the browser API, so I
> believe that sub protocol designs need to be restricted to what can be
> achieved without API changes or IANA allocations.   I think this is a
> good thing and keeps the barrier low for sub protocol development.
>

I expect that IANA registrations of opcodes will end up being specific 
to a particular subprotocol, but I could be wrong. We'll have to see how 
things turn out. But I would be surprised if this draft turned out to be 
the last one that wanted to use opcodes to define message types.

As for the barrier to entry for subprotocols, I am only suggesting that 
a few subprotocols with clear needs will want to define new opcodes. And 
I am hopeful that eventually browsers will provide APIs for people to 
plug in their own extensions.