Re: Streams and Blobs

On Thu, Mar 7, 2013 at 9:40 PM, Jonas Sicking <jonas@sicking.cc> wrote:

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

But what about the issues I mentioned (you snipped them)?  We would be
introducing overlap between XHR and every consumer of URLs
(HTMLImageElement, HTMLVideoElement, CSS loads, CSS subresources, other
XHRs), which could each mean all kinds of potential script-visible interop
subtleties.

Some more issues:

- What happens if you do a sync XHR?  It would block forever, since you'll
never see the Stream in time to hook it up to a consumer.  You don't want
to just disallow this, since then you can't set up streams synchronously at
all.  With the "XHR finishes immediately" model, this is straightforward:
XHR returns as soon as the headers are finished, giving you the Stream to
do whatever you need with.

- What if you create an async XHR, then hook it up to a sync XHR?  Async
XHR only does work during the event loop, so this would deadlock (the async
XHR would never run to feed data to the sync one).

- You could set up an async XHR in one worker, then read it synchronously
with XHR in another worker.  This means the first worker could block the
second worker at will, eg. by running a blocking operation during an
onprogress event, to prevent returning to the event loop.  I'm sure we
don't want to allow that (at least without careful thought, eg. the
"synchronous messaging" idea).


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

It would be less consistent, not more.

With the supply-the-stream-and-it's-done model, XHR follows the same model
it normally does: you start a request, XHR does some work, and onload is
fired once the result is ready for you to use.

With the runs-for-the-duration-of-the-stream model, when is the .response
available?  You can't wait for onload (where it normally becomes
available), because that wouldn't happen until the stream is finished.  The
author has to listen for readystatechange and check for the LOADING state,
which is inconsistent with most of XHR.  (Apparently "text" works this way
too, but that's an incremental response, not a one-time event.)

-- 
Glenn Maynard