W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2013

Re: Streams and Blobs

From: Anne van Kesteren <annevk@annevk.nl>
Date: Tue, 26 Feb 2013 17:12:04 +0000
Message-ID: <CADnb78gMx2gna2Vgvhxi=dqmzEM5i1Dn8xFvPJ_6V=JTKEQ0uw@mail.gmail.com>
To: Aaron Colwell <acolwell@chromium.org>
Cc: WebApps WG <public-webapps@w3.org>
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

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.

Received on Tuesday, 26 February 2013 17:12:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:58 UTC