Re: Streams and Blobs

On Mon, Mar 11, 2013 at 3:03 AM, Jonas Sicking <jonas@sicking.cc> wrote:

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

You seem to be saying that synchronous XHR would return at LOADING, then
keep working in the background to feed the Stream.  This would be very
inconsistent.  Synchronous XHR returns to the caller when it enters the
DONE state, and once it does, its work is finished.

Also, returning to the original point: threads could block each other,
threads could deadlock each other, and a thread could deadlock with itself.

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


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

That's just one of five modes (text vs. arraybuffer, blob, document,
json).  So, I think it's reasonable to say that providing the result at
onload isn't inconsistent with XHR's model; only text mode is inconsistent,
if anything.

(I don't really think text mode is deeply inconsistent, either, but that's
a bit of a tangent...)

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

The current spec does define it that way, at least, which makes sense for
parity with Blob.

(By the way, let's refer to states by name, so I don't have to check the
spec each time to remember what "3" means, and so we don't encourage people
to use those magic constants in their code.)

-- 
Glenn Maynard