Re: [hybi] Framing take IV

[Scott Ferguson <[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?
>   

Essentially all web sockets data is dynamic. We're not sending static files.

Data from a chat application is dynamic
JSON is dynamic
SOAP/XML is dynamic
XMPP over websockets is dynamic.
> 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.
>   

This is incoherent.

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

This also makes no sense.

-- Scott