Re: Streams and Blobs

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
>