Re: Streams and Blobs

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

> On Tue, Feb 26, 2013 at 7:16 PM, Darin Fisher <darin@chromium.org> wrote:
>
>> Interesting idea, but what is the motivation for this change?  Why would
>> the XHR (data provider) state machine need to change?
>>
>
> XHR is a consumer, not a provider: it consumes data from the HTTP stream
> and returns it in one form or another.
>

I was thinking of XHR as the proxy between the underlying HTTP stream and
the Stream object.  Since XHR is used to setup the HTTP stream, it seemed
reasonable to think of it as the producer.  But, I see your point...
especially when you think about progress events and such.



>   The provider is the HTTP stream itself.  If XHR continues to run and
> read data from the HTTP connection after creating the Stream, that
> essentially means we have two consumers for the same provider.
>
> That's confusing.  For example, if nobody is reading from the Stream, you
> want to stop reading from the TCP socket so data buffers and the stream
> backs up.  If XHR continues to be a consumer of the HTTP stream (as it is
> in other modes), then it would keep reading full-speed from the socket even
> if the Stream isn't being read.  (That, or it means it "ghosts" along as
> the Stream is read by some other API, which is weird.)  It also means we
> have two objects returning things like progress events for the same stream,
> which is trickier to get right--you'd need to define the ordering for the
> two sets of events, which probably happen in different task sources.  By
> getting XHR out of the picture as soon as its work is done, all of this
> goes away.
>
>
I didn't mean to suggest that XHR would continue consuming data from the
HTTP stream.  I just assumed that XHR would remain a controller for the
Stream.  For instance, I assumed that XHR.abort() would continue to work,
but that doesn't seem like a requirement.  The approach you outline seems
reasonable.

Hmm, now I wonder how window.stop() should work with a Stream generated
from XHR.  Should window.stop() interrupt the Stream?  My assumption is
that it should since it is backed by a network request.

I assume that even if the Stream is not done downloading that it should be
safe to reuse the XHR object that provided the Stream, right?  Hmm, I can
imagine some implementation complexity arising from saying that a XHR is
done before the Stream is done.

-Darin



> Think of it as if XHR always reads from a Stream object, and all it's
> doing in "stream" mode is stopping after headers and giving you the
> underlying stream to do something else with.
>
>
>
>>  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.
>>
>
> It's not just pausing, it's resuming the stream after the TCP connection
> is closed for any reason, like a network hiccup.  Everyone should want to
> get that right, not just people who want to support pausing.  This is a
> problem for every application using this API, and it seems tricky to get
> right, which in a web API suggests there's something wrong with the API
> itself.  Handling seeking seems even harder.  If people use GET requests,
> and don't interject XHR in at all, the whole category of problems goes away.
>
> What are some actual use cases?  I don't think any have been mentioned on
> this thread.
>
> --
> Glenn Maynard
>
>