Re: [hybi] max frame size, was: frame length encoding

[gustav <[e-mail]>]

On 22 August 2010 18:50, Julian Reschke <[e-mail]> wrote:

> On 22.08.2010 18:39, John Tamplin wrote:
>
>> ...
>> Just because the JS API today passes the messages totally in RAM, there
>> is no reason that it can be extended to support a stream-like API if
>> processing larger messages becomes justified.  However, at the framing
>> level, we have to have something in place such that v1.0 implementations
>> written against this spec can interoperate with later extensions, so it
>> seems prudent to make sure the protocol is sufficient for any reasonably
>> forseeable needs.  There were several strong arguments that 32-bits
>> isn't enough, and the next logical step up is 63/64-bits.
>>
>> Personally, I would be perfectly happy with a 32-bit maximum frame
>> length, and let senders fragment larger messages.  However, there were
>> significant objections (see the discussions link from
>> http://www.ietf.org/mail-archive/web/hybi/current/msg03399.html for
>> details) about being required to fragment a message when its size was
>> known, and the fact that it made "fire and forget" of sending the
>> message contents with a single sendfile() call impossible (when larger
>> than 4G).  Thus, it seemed likely the only way to gain consensus was to
>> support a maximum frame length much larger than 32 bits.
>> ...
>>
>
> Well, we need only rough consensus.
>
> 32 bits has the advantage that it's big enough for almost all use case we
> can currently think of.
>
> 32 bits has the drawback that people who cross the 2/4GB barrier might
> encounter interop problems because of insufficient testing.
>
> One way to address this problem are BIG WARNINGs in the spec, and a test
> suite.
>
>
"Rough consensus" as you and one more person runs the rest over or exactly
how do you mean ?.

"Interop problems". so your trying to quantifify programmers assumed
incompetence in this very specific detail and use it as an  argument ? =)
Even if your right - so what ? , that's how it always is with new stuff, and
how people tend to be,  should that be a valid argument to stop innovation
?. it can be used against everything !

I was against 63/64 bit frames too, but now when i heard peoples arguments,
i agree that its good to have,
especially since we can still get optimal bandwidth encoded  short frames,
option2 and some later proposal offers that.


regards
  gustav trede