[whatwg] WebSocket framing

[Ian Hickson]

On Sun, 21 Aug 2011, Bronislav KluÄ~Mka wrote:
>
> 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.

Whether the frames are split into multiple frames or not is a browser 
decision; at the API level you just say what to send and let the browser 
take care of it. It doesn't have to be kept in memory; in fact, if you're 
sending a Blob, for example, it's quite possible that the whole thing will 
never be stored in RAM. In certain architectures it might never be stored 
in RAM, but be sent straight from the disk controller to the network 
controller bypassing RAM and the CPU entirely.


> 2/ The same issue for receiving. I understand the need for simple API. 
> But again, there is streaming ability missing, all data are received at 
> once. Receiving large amount of data could hang up browser. There should 
> be onFrameMessage event intercepting frames one by one and (probably by 
> some event property) define, whether all those frames should be cached 
> and finally exposed by onMessage event (true by default). Programmer 
> than can choose to ignore such event (not implement it) and receive all 
> messages by onmessage event or implement it, use it for streaming, and 
> possibly prevent onMessage calls and unnecessary caching of large data

Supporting sending and receiving streams is something that we'll probably 
add in due course. First we have to actually have streams at all in the 
Web platform.


> 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> |property 
> if changed during data receiving.

I don't really follow here. Isn't the type just going to be what you ask 
for?


On Mon, 22 Aug 2011, James Graham wrote:
> 
> 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).

Indeed.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'