Re: Streams and Blobs

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

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