Re: [hybi] Fwd: The MessageBroker WebSocket Subprotocol

[Greg Wilkins <[e-mail]>]

On 3 October 2011 05:21, Bruce Atherton <[e-mail]> wrote:
> 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.

Bruce,

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.

The way we have defined the protocol, opcodes are a constrained and
regulated resource that must be allocated by IANA. They may be used by
extensions, which themselves have a high barrier to deployment as they
need to be implemented in the browsers and servers, since the
application API is insufficient (and inappropriate) for implementing
extensions.

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.

regards