Re: MediaRecorder and using Streams

Sure. Using Stream here would rely on some of those changes (especially
explicit read-and-discard model for streams).

The main advantage would be to get MediaRecorder out of the business of
traffic coordination and reuse suitable File API constructs for that. Of
course, this presumes we have suitable constructs. :-)

Jim:

Re-using Stream here would end up being very similar to the ondataavailable
handler invocations, but with helpful back pressure constructs available if
you care. (For example, by providing a StreamBuilder you can signal the
producer to try to keep the buffer fuller than some threshold value.) The
rework of Stream should make consumer pressure a la ondataavailable more
friendly as well.

So the API then becomes:

Stream s = recorder.record();
s.readAsBlob();
---> Read the entire stream as a blob. This is the one-shot record "do
something magic and give it to me when you're done" use case.

recorder.record(StreamBuilder(myPersistentStoragFile);
--> Record to a known persistent storage location with all the right quota
semantics, persistent known location, etc.

Agreed the streaming use case is uglier in the present Stream world, given
the one-shot use of readers in the File API:

Stream s = recorder.record();
StreamReader reader.readAsBlob(s, maxSize);
reader.onloadend = handleBlob;

function handleBlob(reader) {
  sendBlobToServer(reader.result);
  StreamReader reader.readAsBlob(s, maxSize);
  reader.onloadend = handlBlob;
}

But the Promise-based approach which eliminates single-use readers should
make this more ergonomic. But that's hopefully a big part of the benefit --
using a standard File API construct will let the API be more composable as
that construct grows more capable.





On Thu, Aug 1, 2013 at 3:30 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Wed, Jul 31, 2013 at 8:05 PM, Rachel Blum <groby@chromium.org> wrote:
> > Would love to hear your thoughts,
>
> FYI: The Streams API is not happening as is. public-webapps@w3.org is
> discussing alternative designs at the moment.
>
>
> --
> http://annevankesteren.nl/
>
>