Re: Streams and Blobs

On Wed, Feb 27, 2013 at 7:24 AM, Glenn Maynard <glenn@zewt.org> wrote:

> On Wed, Feb 27, 2013 at 12:02 AM, Darin Fisher <darin@chromium.org> wrote:
>
>> 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.
>>
>
> Out of curiosity, what's the complexity?  Once XHR enters DONE, doesn't
> calling open() again pretty much throw away the whole internal state of the
> client and start from scratch?
>

My assumption was that XHR can be reused. I was assuming that the Stream
would just be closed and  any code that still had a handle to this Stream
could read the remaining data if it wished. XHR would create a new Stream
object when a new request was initiated.

On Wed, Feb 27, 2013 at 7:24 AM, Glenn Maynard <glenn@zewt.org> wrote:

> On Wed, Feb 27, 2013 at 12:59 AM, Tillmann Karras <tillmann@selfnet.de>wrote:
>
>> On 2013-02-27 02:55, Glenn Maynard wrote:
>>
>>> What are some actual use cases?  I don't think any have been
>>> mentioned on this thread.
>>>
>>
>> - 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.

On Wed, Feb 27, 2013 at 7:24 AM, Glenn Maynard <glenn@zewt.org> wrote:

> On Wed, Feb 27, 2013 at 12:59 AM, Tillmann Karras <tillmann@selfnet.de>
>  wrote:
>
>> On 2013-02-27 02:55, Glenn Maynard wrote:
>
> - Another one would be downloading only the beginning of a file, e.g. for
>> file type identification / thumbnails/ MP3 tags and so on. (How much data
>> is needed is probably not known up front and just using increasing Range
>> headers would require multiple round trips.)
>> - Jonas mentioned incremental rendering of large Word or PDF documents.
>>
>
> 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.


On Wed, Feb 27, 2013 at 7:24 AM, Glenn Maynard <glenn@zewt.org> wrote:

> The use cases I'm asking for are where you want to hand a stream off to a
> native API like <video>, but where you can't arrange it so it's a simple
> URL--that is, where you need to make a POST request or set custom headers
> in the stream request.  I can't think of any good reason to do this.  For
> example, you might need to authenticate with a POST before starting to
> stream, but that'd be better done by doing a separate POST, receiving an
> authentication token in response, then putting the token in a simple URL to
> be used for the actual stream, or in a cookie depending on security needs.
> The stream itself shouldn't be POST.


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.

Aaron