Re: [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 
>  |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.   `._.-(,_..'--(,_..'`-.;.'

Re: [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.klu...@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


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

Re: [whatwg] WebSocket framing

[Bronislav Klučka]

On 21.8.2011 18:44, John Tamplin wrote:

On Sun, Aug 21, 2011 at 5:05 AM, Bronislav Klučka<
bronislav.klu...@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

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

Re: [whatwg] WebSocket framing

[John Tamplin]

On Sun, Aug 21, 2011 at 5:05 AM, Bronislav Klučka <
bronislav.klu...@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
>
> 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.


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

-- 
John A. Tamplin
Software Engineer (GWT), Google

[whatwg] WebSocket framing

[Bronislav Klučka]

Hello,
I'm looking at current WebSocket interface specification
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.


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


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


Brona Klucka