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

Re: Streams and Blobs

From: Jonas Sicking <jonas@sicking.cc>
Date: Fri, 15 Mar 2013 03:07:52 -0700
Message-ID: <CA+c2ei-vLVan9eH=TgFBzBxjjDnAV64cCCWmfSQGkgc3QXKVWw@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: WebApps WG <public-webapps@w3.org>
After pondering this over for a few days, here's what I propose.

For an async XHR, if .responseType is set to "stream", then when we
reach the HEADERS_RECEIVED state .response is set to a Stream object.
(See more about this below)

As data is being downloaded, we add the data to the end of the Stream
and then fire the normal ProgressEvent events on the XHR object.
Putting data into the Stream might cause other actions to happen,
including firing of events. These actions thus happen before the
ProgressEvent is fired on the XHR object.

For a sync XHR in Workers, if .responseType is set to "stream" when
XHR.send() is called, we block until the HEADERS_RECEIVED state is
reached. At that point we return from the .send() function and return
a newly constructed Stream object. Note that reading from the Stream
object should likely not be permitted synchronously, even within
workers. So all that's synchronous here is waiting until we reach the
HEADERS_RECEIVED state.

There is an additional issue that needs to be resolved however. What
does the following code do?

var xhr = new XMLHttpRequest();
xhr.open("GET", url);
xhr.send();
xhr.onreadystatechange = function(e) {
  if (xhr.readyState != xhr.HEADERS_RECEIVED) {
    return;
  }
  xhr.response === ""; // true
  xhr.responseType = "stream";
  xhr.response instanceof Stream; // true or false?
  xhr.responseType = "text";
  xhr.response === ""; // true or false?
}

We normally allow setting .responseType during the readystatechange
handler for the HEADERS_RECEIVED state transition. But it seems silly
if you have to wait for the event handler to exit before you can get
at the Stream object. But it also seems weird that xhr.response would
synchronously change into a Stream object when .responseType is set to
"stream".

Granted, we do currently synchronously change .response from empty
string to null when .responseType is set to something other than "" or
"text". But it seems weird to allow setting .responseType to "stream",
grabbing the Stream object, and then setting .responseType to
something else.

I guess we could always make the Stream object immediately produce an
error if .responseType is changed to something other than "stream".

As far as I can tell this problem exists in all solutions for using
streams that have been discussed so far. I.e. it's not specific to any
properties of the above proposal.

/ Jonas
Received on Friday, 15 March 2013 10:12:48 GMT

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