Re: [hybi] Framing take IV

As far as I can tell, what Jamie proposed is basically equivalent to what I
proposed in http://www.ietf.org/mail-archive/web/hybi/current/msg02726.html -
the problem with this approach is that it doesn't work well for extensions
that need a variable amount of space in each frame. For something like
multiplexing, compression, or fragmentation it works fine as you have a
fixed number of bits in each frame, but if you wanted to do something like a
mime extension, you would have to reserve a large number of bits in each
frame to make sure you had enough. At least, if I am understanding the
proposal correctly.

That said, it has a very nice advantage in that I don't have to parse
header-goo on each frame, and that the data I care about is at a
well-defined position, at least for all frames in a single client-server
channel (if a different client negotiates a different set of extensions,
that would be different, obviously.)

-Ian

On Tue, Aug 3, 2010 at 7:46 PM, Greg Wilkins <gregw@webtide.com> wrote:

>
> Jamie,
>
> Interesting idea.  I think we had assumed that negotiating extension
> opcodes would be too complex, but what you have suggested looks like the
> start of a simple solution.   Could you care to expand on it a bit more with
> exactly how the client/server would agree on a final set of extended
> op-codes?
>
> So it looks now like we have  4 possible extension approaches:
>
> hixieasque - extension via defined opcodes
> jamiesque - extension via negotiated opcodes
> robertoesque - extension via per frame meta-data
> martineque - extension via a dedicated mime frame
>
>
> cheers
>
>
>
>
> On 4 August 2010 12:27, Jamie Lokier <jamie@shareable.org> wrote:
>
>>
>> 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
>>
>
>
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>
>