- From: Darin Fisher <darin@chromium.org>
- Date: Tue, 26 Feb 2013 17:11:45 -0800
- To: Aaron Colwell <acolwell@chromium.org>
- Cc: Anne van Kesteren <annevk@annevk.nl>, WebApps WG <public-webapps@w3.org>
- Message-ID: <CAP0-QpvCWLNLyk_zxiB=W5sst_=Di2LbyNentcrnjpUj8T3u5w@mail.gmail.com>
On Tue, Feb 26, 2013 at 9:40 AM, Aaron Colwell <acolwell@chromium.org>wrote: > > On Tue, Feb 26, 2013 at 9:12 AM, Anne van Kesteren <annevk@annevk.nl>wrote: > >> On Tue, Feb 26, 2013 at 4:50 PM, Aaron Colwell <acolwell@chromium.org> >> wrote: >> > One other data point is that we are using the Stream as an opaque >> handle for >> > routing data to the Media Source Extensions. (See >> > SourceBuffer.appendStream()). The idea here is that it allows the data >> from >> > an XHR to be transferred to the SourceBuffer object w/o having to >> surface >> > the data to JavaScript. The Stream object seemed like a nice >> abstraction for >> > this since it doesn't have the immutable properties implied by Blobs. It >> > also hides the source of the data from MSE which is nice. I'm not saying >> > that Stream is the only way to handle this, but it is why parts of the >> > Streams API are attractive to MSE. >> >> Okay, so we want to keep something like Stream around. Do you need a >> Blob without size kind of object? E.g. that would mean it cannot have >> "chunked" semantics (the stuff you read is thrown away), which is >> something we probably want for XMLHttpRequest. It seems like these are >> the types we've been discussing: >> >> * Blob fixed in size >> * Blob that grows over time >> * Blob that grows over time and shrinks from the start on read >> > > This last one is the use case I'm primarily interested in and I believe it > is what Stream was intended to model. As long as XHR can return one of > these types of Blobs and there is a way for JavaScript to create and feed > data into a Blob of this type, then I'm happy. > In other environments w/ stream concepts, a non-seekable stream, looks like the last one too. It seems really useful for the web platform to provide a way to refer to a stream of data. I can imagine many applications outside of just XHR response handling. Being able to efficiently pipe data from a data provider to a data consumer seems useful. XHR seems like just one example of a data provider. -Darin > > >> >> Not entirely sure which one Stream represents at the moment. Also not >> entirely sure if we want to support this as discrete objects or if we >> want another approach as outlined in earlier emails. >> > > I like having a single object representing the data flow like Stream or a > "growable Blob" does. That is just personal preference though and I'm > interested in hearing arguments for the sequence of Blobs if people have a > particular preference for that model. > > Aaron >
Received on Wednesday, 27 February 2013 01:12:15 UTC