W3C home > Mailing lists > Public > public-media-capture@w3.org > November 2012

Re: revised recording proposal

From: Harald Alvestrand <harald@alvestrand.no>
Date: Fri, 30 Nov 2012 20:00:48 +0100
Message-ID: <50B90260.8000208@alvestrand.no>
To: "Mandyam, Giridhar" <mandyam@quicinc.com>
CC: "public-media-capture@w3.org" <public-media-capture@w3.org>
On 11/29/2012 05:13 PM, Mandyam, Giridhar wrote:
>> It's not unlikely that some implementations that return blob-at-a-time will be considerably faster than some implementations that return file-at-a-time (the variant where file-at-a-time writes/swaps to disk, while blob-at-a-time stays within memory the whole time).
> If RAM is not an issue, you may be right.  But when you are dealing with a limited heap space and the blob is not GC'ed upon consumption then what?
I am not sure I understand how the scenario you posit can be caused by 
anything but a bug.
There are two alternatives:

- The browser (or tab) will crash with an OOM exception
- The browser will eventually GC the blob

In the last case, either the app is written to hold on to the blob, or 
the browser has a bug.

In the first of those cases, either the app will be fixed, or it will 
die in the marketplace.
In the second of those cases, either the browser will be fixed, or it 
will die in the marketplace.

Neither of those seems to be issues that we the standards group need to 
let stop us from doing what's otherwise the right choice.

               Harald
Received on Friday, 30 November 2012 19:01:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:12 UTC