W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

Re: [XHR] support for streaming data

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 18 Aug 2011 15:20:02 -0700
Message-ID: <CA+c2ei-rGAm-8uNwGiO30=LqpZAp+VE0HR7b6_8BLcHrJT-3Ww@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: Chris Rogers <crogers@google.com>, Webapps WG <public-webapps@w3.org>
On Thu, Aug 18, 2011 at 1:16 PM, Ian Hickson <ian@hixie.ch> wrote:
> On Wed, 17 Aug 2011, Chris Rogers wrote:
>> Also, it would be good to get Ian's opinion about this since he's
>> working on similar stuff with Web Sockets.
> Right now WebSockets only works with complete messages, there's no
> streaming support. I suspect that if we add streaming support to the
> protocol and the API, it'll be exposed as some sort of Stream object,
> which would then have a way to get the data out of it in chunked form,
> maybe a growing list of ArrayBuffers or something. I haven't looked at it
> in detail yet.
> There would probably be some relationship to MediaStream, too; roc may
> have an opinion on this topic, as he has spoken about it before.

What we're talking about here isn't really "streaming" as much as
"chunked". The equivalent feature would be to be able to incrementally
get data as a large websocket message was delivered.

The usecase would be something like supporting incremental rendering
of attachments, even when the attachment is sent as a single websocket

However I think it's a bit early to start talking about this feature
for websockets. The websocket API doesn't even have support for
progress events for individual messages. And even the basic API is
still far from widely deployed in browsers.

It's also less important since you can always support the use case by
chunking up the attachment into several websocket messages, and
reassemble them manually in the client. This is more work, but should

/ Jonas
Received on Thursday, 18 August 2011 22:21:07 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:34 UTC