Re: Streams and Blobs

On Tue, Feb 26, 2013 at 5:10 PM, Glenn Maynard <glenn@zewt.org> wrote:

> 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.
>
>
Interesting idea, but what is the motivation for this change?  Why would
the XHR (data provider) state machine need to change?



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

This seems like a problem for the application.  If an error is detected,
then the application can do what it needs to restart the stream.
 Presumably, the application would be built to only create streams that can
be restarted if pausing is a mode it wants to support.

-Darin



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