On Tue, Feb 26, 2013 at 9:12 AM, Anne van Kesteren <ann...@annevk.nl> wrote:
> On Tue, Feb 26, 2013 at 4:50 PM, Aaron Colwell <acolw...@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. > > 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