Re: Streams and Blobs

On Fri, Mar 15, 2013 at 5:07 AM, Jonas Sicking <jonas@sicking.cc> wrote:

> 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.
>

This isn't guaranteed.  Progress events are queued tasks, and the "other
actions" (such as EventSource's onmessage) are also typically queued
tasks.  Since they're from different task sources, the order the tasks are
performed is unspecified.

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.
>

Synchronous XHR returns when it reaches DONE.  Returning at
HEADERS_RECEIVED would be strange and inconsistent.

Not supporting synchronously reading from streams is also strange.  We
should definitely be able to support this, just like we support other
synchronous I/O in workers.  Even if we don't tackle exposing this right
away, having an API design incapable of supporting it would be a serious
mistake.

This all seems to be bending and twisting XHR, and imposing arbitrary
restrictions, in order to try to make the API work in the way you first
envisioned it.  The approach I've suggested doesn't require these
contortions and restrictions.

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

Specifically, I'd recommend that when readyState isn't UNSENT, setting
responseType to "stream" should fail, and if readyState is set to "stream"
then setting it to something else should fail.  That is, once the request
is started it's too late to change into or out of stream mode.

-- 
Glenn Maynard