Re: [hybi] Framing take IV

[Jamie Lokier <[e-mail]>]

Scott Ferguson wrote:
> Ian Hickson wrote:
> >On Tue, 3 Aug 2010, Scott Ferguson wrote:
> >  
> >>>I agree. I can't see any benefit to fragmentation over a variable-size 
> >>>length field for an initial version without multiplexing. If the 
> >>>variable-size length field is well-designed, then in the common case 
> >>>where the message size is small it will only cost one extra branch to 
> >>>read the length. In the rare case where the message size is large, a 
> >>>variable-size length is easier to deal with than reassembling 
> >>>fragments, and easier on the sending side too.
> >>>      
> >>Some of us don't have infinite memory when sending messages.
> >>    
> >
> >Why do you need infinite memory?
> >  
> 
> Because we don't know the length of dynamically produced content until 
> the dynamic process is complete. That's why HTTP added chunking.

I agree (and favour chunking like this), however there is a
counterargument (which shouldn't be assumed to have my support):

The JS API does not permit incremental delivery of parts of a message
as they arrive, so from the JS API perspective, everything is done
with whole messages.

If you have incrementally delivered large messages, it's possible to
write a WebSocket protocol that depends on this (maybe even
bidirectionally) and is usable by non-JS clients, yet is impossible to
use from JS API browser clients.

So if you want to send large messages of unknown size that are sure to
be equally accessible to the JS API as other clients, think in terms
of "joining messages in an application-visible manner" rather than
splitting them.

-- Jamie