Re: Streams and Blobs

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.


>
> 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