Re: Streams and Blobs

On Wed, Feb 27, 2013 at 8:54 AM, Aaron Colwell <acolwell@chromium.org>wrote:

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

+1


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