Re: Streams and Blobs

On Wed, Feb 27, 2013 at 7:24 AM, Glenn Maynard <> wrote:

> On Wed, Feb 27, 2013 at 12:02 AM, Darin Fisher <> 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
doesn't interrupt an existing Stream.


> On Wed, Feb 27, 2013 at 12:59 AM, Tillmann Karras <>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

Received on Wednesday, 27 February 2013 17:40:40 UTC