[whatwg] WebSocket framing

[James Graham]

On 08/22/2011 09:09 AM, Bronislav Klučka wrote:
>
>
> On 21.8.2011 18:44, John Tamplin wrote:
>> On Sun, Aug 21, 2011 at 5:05 AM, Bronislav Klučka<
>> Bronislav.Klucka at bauglir.com> wrote:
>>
>>> Hello,
>>> I'm looking at current WebSocket interface specification
>>> http://www.whatwg.org/specs/**web-apps/current-work/**
>>> complete/network.html#the-**websocket-interface<http://www.whatwg.org/specs/web-apps/current-work/complete/network.html#the-websocket-interface>
>>>
>>>
>>> 1/ and I'm missing the ability to specify, whether data to be sent are
>>> final or not (whether the frame to be sent should be continuous or not)
>>> I suppose some parameter for specifying final/continuing frame should be
>>> there, or some new methods for framing. I've tried to send 100 MiB
>>> text from
>>> Chrome for testing purposes and since there is no way to specify
>>> framing it
>>> was send in one piece. There is no way to stream data from client to
>>> server, all data must be kept in memory and sent at once.
>>>
>> The JS API is entirely at the message level -- the fact that it might be
>> fragmented into frames is an implementation detail of the browser and the
>> rest of the network.
> That was not the point, the point was that current WebSocket JS API does
> not allow streaming of data either from browser or from server (browser
> sends data as one frame, and when receiving exposes to the programmer
> the whole message at once regardless of how server sent the message). As
> persistent and low latency connection, WS would be perfect for streaming
> data. But due to this JS API inability to handle frames, one has to
> implement streaming on server and client all over again even though the
> protocol can be used.
> So the point is, couldn't JS API use the ability of the protocol to ease
> streaming implementation?

I imagine that at some point in the future we will expose an interface 
that is optimised for streaming data over websockets. But it seems 
foolhardy to do that before we have any real-world experience with the 
basic API. It is also something that will need to be designed to 
integrate with other streaming APIs in the platform, e.g. the audio and 
video stuff that is currently being discussed (mostly elsewhere).