Re: Streams and Blobs

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?


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