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

This assumes a refactoring of the guts of XHR to separate the loader
portion so that it can be connected to a Stream and divorced from the XHR
that created it.  The point, I assume, is so that a subsequent XHR.open()
doesn't interrupt an existing Stream.

-Darin


>
>
> 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.
>
>
>> - 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).
>
> 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.
>
> --
> Glenn Maynard
>
>