Re: Streams and Blobs

On Fri, Mar 8, 2013 at 7:52 AM, Glenn Maynard <glenn@zewt.org> wrote:
> 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.

As long as we define the order between when data is going into the
Stream, and when the events are fired on the XHR object, I think that
takes care of these issues.

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

Sync XHR already can't use .responseType, so there is no way for sync
XHR to return a Stream object. We should put the same restriction on
Sync XHR accepting a Stream as a request body.

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

Same as above.

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

This is a good point. We probably shouldn't allow sync XHR in workers
either to accept or produce Stream objects.

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

This is not correct. All of .response, .responseText and .responseXML
are often available much before that.

> With the runs-for-the-duration-of-the-stream model, when is the .response
> available?

Ideally as soon as .send() is called. If that causes problem then
maybe as soon as we enter readystate 3.

/ Jonas

Received on Saturday, 9 March 2013 04:41:23 UTC