On Wed, Feb 27, 2013 at 7:24 AM, Glenn Maynard <gl...@zewt.org> wrote:
> On Wed, Feb 27, 2013 at 12:02 AM, Darin Fisher <da...@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 <tillm...@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 > >