Re: [hybi] Framing take IV

[Jamie Lokier <[e-mail]>]

Ian Hickson wrote:
> On Tue, 3 Aug 2010, 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.
> 
> Is this a common case we should expect? What are the use cases for this?
> 
> If this is a rare occurence, then it's probably simplest to support this 
> at the application layer - nothing stops anyone from having a subprotocol 
> that defines the first byte/character of each message as being a 
> "has continuation" byte.
> 
> If this is a common occurance, then we'll be able to tell when people find 
> themselves often implementing this at the application layer, and then we 
> can easily add it at the WebSocket layer at that time (in a few months). 
> We don't need to reserve bits specifically for it today.

Unusually, perhaps, I'm with Ian on this.

As well as the application approach, assuming we get protocol negotiation,
there is nothing to stop defining a new "continuation frame" type.

That would make trivial WS implementation even simpler: They'd just
ignore the negotiation, so wouldn't receive or need to handle
continuation frames.

(I'm really warming to the idea of a super-simple base protocol on
which just about everything we've discussed works as optional
features, ignorable by simple implementations, used by good quality
implementations automatically ("below the API"), and can be defined in
future without necessarily awaiting standardisation to try them out.)

-- Jamie