W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2013

Re: Streams and Blobs

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 7 Mar 2013 19:40:19 -0800
Message-ID: <CA+c2ei8oB4s1dr694Lk4Ut6aA2CH71TQVcH-MN9XwJ_KF4-09Q@mail.gmail.com>
To: Glenn Maynard <glenn@zewt.org>
Cc: Anne van Kesteren <annevk@annevk.nl>, WebApps WG <public-webapps@w3.org>
On Thu, Mar 7, 2013 at 4:42 PM, Glenn Maynard <glenn@zewt.org> wrote:
> The alternative argument is that XHR should represent the data source,
> reading data from the network and pushing it to Stream.

I think this is the approach I'd take. At least in Gecko this would
allow the XHR code to generally do the same thing it does today with
regards to actions taken on incoming network data. The only thing we'd
do differently is which consumer to send the data to. We already have
several such consumers which are used to implement the different
.responseType modes, so adding another one fits right in with that
model.

>From an author point of view it also means that the XHR object behaves
consistently for all .responseTypes. I.e. the same set of events are
fired and the XHR object goes through the same set of states. The only
difference is in how the data is consumed.

The XHR object and the stream would still be separate objects. So
aborting the XHR object would not affect the behavior of the Stream
object, other than that it would stop further data from becoming
readable through the stream. Possibly the stream would also indicate
some sort of "abort" error once the end was reached.

/ Jonas
Received on Friday, 8 March 2013 03:41:16 GMT

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