Re: Streams and Blobs

On Sat, Mar 9, 2013 at 8:03 AM, Glenn Maynard <glenn@zewt.org> wrote:
> On Fri, Mar 8, 2013 at 10:40 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>> > - 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.
>
> Now you can't stream synchronously, and now XHR suddenly cares about whether
> an object URL comes from a Stream instead of being protocol-agnostic
> (meaning black-box APIs that take a URL won't working with them either).
> This is adding weird restrictions to work around problems with the design.

Indeed, returning a Stream from a sync XHR in workers would be fine.
And in that case you should do that as soon as the headers data has
been successfully parsed.

>> > 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.
>
> Nope.  The only time any of these is available (per spec) before the DONE
> state is in responseType = "text", making that the exception.  All the rest
> are only available in DONE.  The most common pattern with XHR is to call
> send(), then wait for onload (or one of the other redundant events fired at
> that time), which this approach follows.

I was wrong about .responseXML. But I'm correct about .response and
.responseText.

>> > 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.
>
> You need to know the MIME type to create a Stream, so you can't create it
> until you've received headers.

That seems to depend on how we define Stream. But if we define it as
having a known mimetype then indeed readystate 3 is what we'll have to
wait for.

/ Jonas

Received on Monday, 11 March 2013 08:04:14 UTC