Re: Streams and Blobs

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

> On Wed, Feb 27, 2013 at 10:39 AM, Aaron Colwell <acolwell@chromium.org>wrote:
>
>>  - I would like to stream realtime TV. Pausing shouldn't be a problem
>>>> because I don't rely on POST requests and I would just buffer up to a
>>>> certain limit.
>>>
>>>   - Another use case that comes to mind is starting to watch a video
>>>> file before it is fully downloaded.
>>>>
>>>
>>> You don't need XHR or Stream for this.  Just point video @src at the
>>> stream.
>>>
>>
>> In the Media Source Extensions context it is valuable to be able to
>> consume the data as it arrives instead of waiting for the whole transfer to
>> complete. The normal use case for MSE involves chunks of media several
>> seconds long and it is important to be able to process the data as it
>> arrives to help minimize startup time and media prefetching.
>>
>
> (This reply doesn't seem related to the text you're quoting.  Tillmann
> said he wants to be able to stream TV.  You don't need any of this to do
> that; <video> can do it already.)
>
> Sending data to MSE, or any other API, doesn't mean it has to be done with
> XHR.  Simply handing over a URL is much simpler.  Why do you want to go
> through XHR in any of these cases?
>
>  On Wed, Feb 27, 2013 at 7:24 AM, Glenn Maynard <glenn@zewt.org> wrote:
>>
>>> These are separate.  We're talking about taking the result of an XHR and
>>> handing it off to a native API like <video>.  There's a separate discussion
>>> for incremental reads in JavaScript, which doesn't involve Stream at all
>>> (search the thread for clearResponse for my rough proposal).
>>>
>>
>> Why do these need to be thought about differently? It seems to me that
>> Stream simply represents a non-seekable stream of bytes. It seems
>> convenient to be able to hand this object to MSE, video, or any other
>> object native or otherwise that wants to consume such a stream. If
>> JavaScript needs access to the bytes then something like the StreamReader
>> seems reasonable to me just like FileReader seems reasonable for accessing
>> Blob data.
>>
>
> The whole initial point of this thread is that the Streams spec is a lot
> of API for streaming to script.  In response, the only argument made for
> Stream is for handing streams off to native (video or anything else).  If
> that can't be justified with use cases, then we're back where we
> started--if the only use cases we have are for streaming to script, we
> don't need Stream for that.  All we need to have to support that is one new
> method (and maybe another property, depending on web-compatibility).
>
> "It seems convenient" isn't good enough to justify adding something to the
> web, if there's a much simpler, more reliable way to do the same thing.
>
> I don't see why the difference between POST or GET usage matters. The XHR
>> is just being used to fetch data. I don't think we should bake any
>> assumptions into which methods people use.
>>
>
> The difference, more precisely, is between using XHR to initiate a fetch
> and just handing in a URL for the resource.  ("POST" vs. "GET" is a mild
> oversimplification of that, since POST is one thing you can't do by passing
> in a URL.)
>
> There's a huge, fundamental difference between a URL and an XHR-provided
> POST.  If you have a simple URL, eg. <video src=url>, the browser can open,
> close and seek the URL in any way it needs to.  The browser can handle
> pausing, seeking, and recovering interrupted streams, completely
> automatically.  If you have a POST initiated from XHR, the browser can't do
> any of that and it all gets pushed onto the developer.  (Even if it's a
> GET, it's not clear that the browser could restart it if it comes from XHR.)
>
> On Wed, Feb 27, 2013 at 10:54 AM, Aaron Colwell <acolwell@chromium.org>
>  wrote:
>
>> 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.
>>
>
> I think this may be a more complicated model that will be harder to
> precisely define.  But, I don't think the need for the feature has been
> established, so for now I'll focus on that part of the discussion.
>
>  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.
>>
>
> But again: what cases are those?  Why would you use XHR, create a Stream
> and pass the Stream to another API, instead of just giving the API the URL
> in the first place?
>
>  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.
>>
>
> I'm simply asking: what use cases there are for creating a stream with XHR
> and handing the stream off to another API, that can't be done much more
> simply by handing a URL to the other API in the first place?
>
>
It's a fair question, and I think you've made a lot of good points.  I
think XHR gives you the ability to customize the HTTP request.  You can set
custom request headers, customize the request method, control cross-origin
behavior, etc.  It gives the developer a lot of flexibility.

Another thing not to lose sight of is that a Stream abstraction could be
useful as an optimization tool.  There are times when a developer just
needs to connect a data stream from a provider to a consumer and doesn't
necessarily care about seeing the raw bytes.  (The data may not even be
available in the address space of the process running the developer's
script.)  So, I can imagine some optimization opportunities when we work
with a handle to a stream of data rather than the data itself.

-Darin


> --
> Glenn Maynard
>