Re: [hybi] Framing take IV

[Jamie Lokier <[e-mail]>]

Greg Wilkins wrote:
>    Neither of these problems are show stoppers, although they do combine
>    badly.. ie multiplexing can be done with a channel switch and flow
>    control frames, but only if op-codes are allocated to it and that will
>    need centralized consensus on one true multiplexing algorithm.

Will it?  If those op-codes are negotiated, then multiplexing becomes
an optional extension, and multiple competing extensions are perfectly
interoparable with each other.  It's also fine for an implementation
to offer multiple ways to do the same thing, if the negotiation is
sensible.

I think that's better than choosing the one true multiplexing
algorithm, not least because there probably isn't an ideal algorithm
for all apps, and some specialised clients and their servers may
prefer to use a different one.

>    There are many variations on these themes, but I think these are the 3
>    basic approaches that have been identified, which I will call:
>     1. hixiesque - centralized extension via op-codes
>     2. robertoesque- per frame extension via meta-data
>     3. martinesque - extension via dedicated mime frame (meta-data plus
>        data)
> 
>    Any others?

4. Extension codes identified at handshake negotiation time, or a
later negotiation time in control messages.

For example: "WebSocket-Protocol: x-multiplex;control-byte=12, keepalive-aggregator;control-byte=13"

Doing it at handshake time has the advantage that it's easily
future-proof, very little needs to be defined up front, and simple
implementations can ignore them entirely.

-- Jamie