Re: [hybi] complexity explosion

[Justin Lee <[e-mail]>]

OK.  That helps to know.  That's a nice summary.  I hadn't been able to
glean that from the discussion so far.  Thanks for the clarification.

On Wed, Aug 18, 2010 at 10:53 AM, John Tamplin <[e-mail]> wrote:

> On Wed, Aug 18, 2010 at 10:22 AM, Justin Lee <[e-mail]> wrote:
>
>> Well, for example, the framing discussion.  At 64 bits, that's still crazy
>> large.  Hell, move it up to 128 if you really want to support sending full
>> movies via on websocket frame.
>
>
> When you read back over the discussions, you will see that there are in
> fact people who wanted to send a full DVD movie in one frame, so they could
> just had it off to the kernel.  The v76 protocol supported an arbitrary
> number of bits of length, so you had to be prepared to handle multiprecision
> arithmetic to properly implement the spec -- at least now you know you need
> a fixed 64-bit integer.
>
>
>> All this back and forth about partial this and multiplexing that.
>
>
> Note that multiplexing specifically will not be included in the base
> protocol.  The discussion about it is so that we can add it later without
> having to break backwards compatibility, which means that you implementing
> v1.0 of the spec won't have to worry about it ever unless you actually do
> want to participate in multiplexing.  Fragmentation has been accepted as a
> requirement of the base protocol, partly to support later extensions, so
> that is complexity you will have to deal with, but it really shouldn't be
> that bad.
>
> To implement the current proposal, if you never negotiate any extensions
> during the handshake then it is simply a length, an opcode, and
> fragmentation flags, and if the short length is 127 then you read the long
> length, and then the payload bytes.
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>



-- 
You can find me on the net at:
http://www.linkedin.com/in/justinlee
http://www.twitter.com/evanchooly