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

Yes it consume the data from the server, but it provides it to the Stream.

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

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

That is not how I was assuming it would work. I assumed it would keep
reading & buffer the data just like a normal XHR would do in the other
modes.

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

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

Yes. This is what I would expect.

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

>   (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'm viewing XHR as controlling the connection to the server and
representing the progress of the data reaching the client. Progress on the
Stream just represents when the Stream received data, from XHR or whatever
other source created the object.

In my opinion keeping XHR in the picture the whole time allows it to act
just like it would if it was being used in all the other modes. I don't
really see a need to special case this.

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

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

I think this may be where we have a difference of opinion. I'm thinking of
XHR as the source of the stream not a reader of it. This is mainly because
the stream represents  the body of the request, not the socket itself.

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

I don't expect XHR to have to deal with pausing. In most cases where the
video tag would use Stream it would be for a live stream where pausing
isn't an option. Even if it was, since all the video tag has is a
non-seekable stream of bytes, it would have to either do its own caching or
just give up and signal an error. It can't make any assumptions about the
request because it doesn't know where the stream of bytes are coming from.
Here we are only talking about XHR, but it could be from JavaScript, a
WebSocket, or something else. The application knows that it is restricting
the video tag in this way when it chooses to pass in a Stream. If pausing
needs to be supported then Stream shouldn't be passed to the tag directly.
Something like MSE or a standard video.src = URL should be used.

Hope this helps,
Aaron