[hybi] Fwd: frame length encoding

[Brian <[e-mail]>]

>
> 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.
>

Yes.  What is "reasonable" is what I'm getting at.  Compression and
fragmentation seem reasonable... multiplexing seems like something that
should be handled by the subprotocol to me, as most of them won't need it
and how to multiplex seems more likely to depend on the subprotocol itself.

As for the arguments for 63/64 bits, I don't think they were that strong.  I
think it's more that fewer people felt like expending the energy to debate
them and keep the discussion on track in terms of what this protocol is for,
so the edge case people won.

If JavaScript-based browser clients are truly thought to be doing something
useful with large frames >4GB, then fine, though I doubt it.  Even an abuse
of WS like video streaming would use a series of shorter frames in practice.
 If that length requirement was envisioned for usage outside of JS and the
browser, then it's not appropriate.



>
> 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.
>
>
Yes.  That whole sendfile() debate, from where I'm sitting, was completely
irrelevant to the discussion of a protocol meant to enable realtime
bi-directional communications with browser clients.

The purpose of this protocol is basically to enable the kinds of
communications that Comet attempts to solve by abusing the HTTP protocol,
and to open new frontiers to things we haven't considered doing in the
browser yet (binary frames etc).  Some things are useful and easy to throw
in.  Some things are just a distraction from the true purpose of the
protocol.  64-bit lengths is "easy to throw in" until a discussion of the
details consumes a full week+ of the working group's extremely valuable
time.  At this point, we need to pick something and put a bow on it so it
doesn't cost any more than it already has.


Brian