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