Re: [hybi] Framing take IV [why fragment]

[Scott Ferguson <[e-mail]>]

Dave Cridland wrote:
> On Thu Aug  5 16:26:23 2010, Scott Ferguson wrote:
>> Dave Cridland wrote:
>>> On Wed Aug  4 15:33:13 2010, Patrick McManus wrote:
>>>
>>>> Benefits of streaming:
>>>>
>>>> * Reduced memory consumption on the sender in cases where the 
>>>> message is
>>>> being "passed through". A service that does a large database query 
>>>> is a
>>>> good example here - the results can be passed back as they are found
>>>> even before you know how many there are.
>>>>
>>>>
>>> No, because the receiver cnnot process portions of messages - at 
>>> least with our current API. And you can achieve this behaviour by 
>>> sending multiple messages anyway.
>>
>> Of course it can. Browser writers are fully capable of buffering the 
>> frames until the message is complete and then giving the complete 
>> string to the application.
>>
> Right, giving no benefit to the application, which was my point.

The bulk of the application is on the server.

The browser has infinite memory, infinite CPU, and a single user. That's 
why they could chose a string-based API instead of a streaming API.

The bulk of any websocket application will be on the server, just like 
the bulk of any HTTP application is on the server now. The bulk of 
application developers will be on the server, just like HTTP now. The 
bulk of the application complexity will be on the server.  Anything that 
makes the server application easier to develop is a benefit to the 
application.

Server code like PHP scripts are built around a solid streaming 
programming model, and that's been enormously successful, particularly 
for the "amateur" programmers. Throwing that successful programming 
model away with no good reason is absurd.

-- Scott

>
>> The browser developers never complained about the sentinel framing 
>> and it has the exact same buffering requirement.
>
> I'm not saying it doesn't. :-)
>
> I am saying that this means this is not a good argument for chunking.
>
> Dave.