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

[XHR] support for streaming data

From: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 8 Aug 2011 17:13:20 -0700
Message-ID: <CA+c2ei8aZxeW6T+ctYgdHcY67N3OrxDDgLY1H_DBndtkcc4zzw@mail.gmail.com>
To: Webapps WG <public-webapps@w3.org>
Hi All,

XHR Level 2 does wonders for making XMLHttpRequest better. However
there is one problem that we have run into with "streaming" data.

Using .responseType="text" you can read the contents of the data as
soon as it comes in, i.e. you don't have to wait for the "load" event
to read the data. However you can't do the same for .responseType =
"arraybuffer". This is with good reason as arraybuffers are immutable
in size and you can't really know how much data you'll receive up
front. (You can make guesses based on the "content-length" header, but
it's not always there, and isn't always reliable even when it's
there).

Another problem is that even if the webpage is able use
.responseType="text" and consume the data in an incremental manner,
the UA still ends up accumulating and holding large chunks of data in
memory.

So in other words, the use case is pages that are able to
incrementally consume binary and textual data and wanting to do so
without having to wait until the whole resource has been downloaded,
and do so without requiring the UA to hold large amount of data in
memory.

To solve this I propose we add two new values to .responseType:
"streaming-text" and "streaming-arraybuffer".

When .responseType is set to "streaming-text" then during each
"progress" event, .response would be set to the text that was received
since the last "progress" event (and since the "loadstart" event for
the first "progress" event).

Same thing when .responseType is set to "streaming-arraybuffer". In
this case .response is set to an ArrayBuffer containing the data
received since the last "progress" event.

There is one non-ideal thing with this solution. Once the last chunk
of data has arrived, at least Firefox doesn't fire a "progress" event,
but instead just a "load" event. This means that people will have to
consume data both from the "progress" event and from the "load" event.

Another solution would to make sure to always fire a "progress" event
for the last data before firing the "load" event. I personally like
this approach more. There *might* even be reasons to do that to ensure
that pages create progress bars that reliably reach 100% etc.

/ Jonas
Received on Tuesday, 9 August 2011 00:14:17 GMT

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