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

Re: [XHR] support for streaming data

From: Charles Pritchard <chuck@jumis.com>
Date: Wed, 10 Aug 2011 17:39:26 -0700
Message-ID: <4E4324BE.5040709@jumis.com>
To: Jonas Sicking <jonas@sicking.cc>
CC: David Flanagan <dflanagan@mozilla.com>, public-webapps@w3.org
On 8/10/2011 5:04 PM, Jonas Sicking wrote:
> The point of streamed XHR is to receive data as soon as it's available
> so that you can process it right away. This also means that you're
> likely going to get the data in pretty small chunks. Hence the use
> cases for streaming are basically the direct opposite of the ones for
> blobs.
I agree. And BlobBuilder is easy to use: there is little need for 
chunked-blob.

> It also doesn't make sense for parsed formats, like XML, HTML or, if
> we add it in the future, JSON, to use streaming. It's unlikely that
> the contents of those can be delivered in chunks, and so it's better
> that we'll just incrementally parse, which is already what happens.

There are streamed XML formats: SVG and InkML come to mind as possibilities.
MP4Box + GPAC lay SVG chunks, and use discard.

InkML would be a likely candidate for streaming live sessions.
I'm fine with one typed array, 'chunked' == arraybuffer,
as I can work from there whether it's text or not.

That is, I don't -need- a chunked-text. If I'm streaming, I'm treating
the data first and foremost as raw bytes.

-Charles
Received on Thursday, 11 August 2011 00:40:08 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:47 GMT