Re: [hybi] Fwd: The MessageBroker WebSocket Subprotocol

[Frank Salim <[e-mail]>]

If you needed more than two types of messages, you would simply put
the message type in the payload. The fact that there are typed
messages at all is an artifact of the API and protocol evolution, not
something to design your protocols around.

Extensions should be used to transform the message stream (for example
by compressing payload bytes). A protocol, on the other hand, defines
an interaction. Protocols should not depend on the presence or absence
of particular extensions.

-Frank Salim

On Mon, Oct 3, 2011 at 9:50 AM, Bruce Atherton <[e-mail]> wrote:
> 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.
>
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi
>