Re: Streams and Blobs

On Tue, Feb 26, 2013 at 11:12 AM, Anne van Kesteren <annevk@annevk.nl>wrote:

> Okay, so we want to keep something like Stream around. Do you need a
> Blob without size kind of object? E.g. that would mean it cannot have
> "chunked" semantics (the stuff you read is thrown away), which is
> something we probably want for XMLHttpRequest. It seems like these are
> the types we've been discussing:
>
> * Blob fixed in size
> * Blob that grows over time
> * Blob that grows over time and shrinks from the start on read
>

For taking an XHR response and handing it off to some native API, the
Stream interface does seem like the right abstraction: it represents a
logical stream, not a block of data like Blob.  The only parts of the
Streams API needed to make this work are the simple Stream interface (which
is nothing but an object with a MIME type) and createObjectURL support for
it.  You don't need StreamReader or StreamBuilder.

You'd want XHR itself to behave a bit differently if it returns a Stream,
though.  It should never enter LOADING, instead finishing as soon as
headers complete, as if XHR hands off the file descriptor to the stream
object as soon as the headers finish.

That said, I'm not fully convinced about the overall picture of Stream:

- What happens if you start a video stream, then the user pauses the video
and goes away?  The browser (or server) will want to shut down the TCP
stream and reopen it again if the user unpauses a day later.  If the stream
comes from an XHR POST, it's not allowed to do that.  Similarly, you have
to deal with restarting the stream after a dropped connection.
- What about seekable streams (eg. streaming large but static videos,
rather than a live feed)?  You can't do it, for the same reason.

If you structure services with the GET, you don't have any of these
problems; the browser can stop, restart and seek the request whenever it
wants; and we don't need any new APIs.  What are the actual use cases for
POST (or other custom XHR-based requests) that are so hard to structure as
a GET (or an initial authenticating POST that replies with a GET URL) to
warrant all this?

-- 
Glenn Maynard