Re: [hybi] Fwd: The MessageBroker WebSocket Subprotocol

[Bruce Atherton <[e-mail]>]

On 02/10/2011 9:51 AM, John Tamplin wrote:
>
> It isn't entirely clear to me whether this is defining a subprotocol 
> or a WebSocket extension.  3.3 clearly makes it seem to be a 
> subprotocol, but then 2.1.2 defines two opcodes, which is something 
> that can only be done by an extension.

As I pointed out in my example with HTTP (which required Request and 
Response message types), it is going to be very common for subprotocols 
to want to define new opcodes. They are the right fit for defining 
message types in a subprotocol.

I did try to suggest that subprotocols should be able to define new 
opcodes, but got push back when I tried. Eventually I realized that 
requiring there be an extension to change opcodes for use with a 
subprotocol was a better solution because then it doesn't put any 
requirements for understanding subprotocols on to intermediaries, which 
would have caused complications for some usecases for the subprotocol 
field such as versioning.

So I foresee a good number of subprotocols will also want to define 
extensions to identify opcodes that they want to use. I think this is 
fine, but in drafts that require this (such as this one)  the definition 
of the extension and the opcodes it defines should probably be in a 
separate section.

>  Also, if it is an extension, there should probably be more care to 
> reduce the number of opcodes used, as they are in very limited supply.

I don't believe that is the case. Every Websocket connection (which may 
be a socket or a channel inside a MUX connection) is going to speak only 
one subprotocol, so they are only going to need one extension defining 
new opcodes for message types.  There is no reason these opcodes cannot 
be reused between different subprotocols. That logic does not apply to 
control opcodes, of course, since they are a Websocket layer concern.