RE: revised recording proposal

The first alternative (OOM) is not a bug in my opinion, but a valid mitigation strategy could be that the UA is allowed to write to disk when memory limits are approached.  But my reading of the File API spec is that a File object can be backed by disk memory, but there is no mention of whether a Blob in general may be backed by disk memory.  If the UA has the flexibility to write to disk when memory limitations are reached, then we have the open issue as to whether the UA can be deemed to be in compliance with the Recording API spec if it returns a File object instead of a Blob.  

-----Original Message-----
From: Harald Alvestrand [mailto:harald@alvestrand.no] 
Sent: Friday, November 30, 2012 11:01 AM
To: Mandyam, Giridhar
Cc: public-media-capture@w3.org
Subject: Re: revised recording proposal

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:22:01 UTC