W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2013

Re: Streams and Blobs

From: Darin Fisher <darin@chromium.org>
Date: Wed, 27 Feb 2013 09:40:12 -0800
Message-ID: <CAP0-QpuPdExWTdEnx5KiccKiqXKGqnu7uE28PnfGPEiEZdmDEg@mail.gmail.com>
To: Glenn Maynard <glenn@zewt.org>
Cc: Tillmann Karras <tillmann@selfnet.de>, public-webapps@w3.org
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.


> 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
Received on Wednesday, 27 February 2013 17:40:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:58 UTC