W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2011

[whatwg] WebSocket framing

From: Bronislav Klučka <Bronislav.Klucka@bauglir.com>
Date: Mon, 22 Aug 2011 09:09:46 +0200
Message-ID: <4E5200BA.7050901@bauglir.com>


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?

>
>> 3/ MessageEvent should expose what kind of data was received, textual, blob
>> or arrayBuffer. This would prevent testing for data type and problems with
>> testing |binaryType<http://dev.w3.org/html5/**websockets/#dom-websocket-*
>> *binarytype<http://dev.w3.org/html5/websockets/#dom-websocket-binarytype>>
>> |property if changed during data receiving.
>>
> At the WebSocket protocol level, there is only text data and byte data.
>   There is no notion of it being sent as a blob or array buffer, and any
> binary data could be received as either, as is convenient to the receiver.
>
This notice was not about how data are sent, but how data are received.
Regardless of data type the message is received by onmesssage event and 
exposed in data property,
but I guess one can test for data type of this property

Brona.
Received on Monday, 22 August 2011 00:09:46 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:35 UTC