RE: revised recording proposal

> From: Mandyam, Giridhar [mailto:mandyam@quicinc.com]
> 
> 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.

My understanding of the differences between blobs and files is _only_ in the set of attributes they expose. The rationale I see for exposing the recorded data as a Blob vs. File, is simply avoiding the issue of what values to put in the File's "name" and "lastModifiedDate" attributes. Since the Blob hasn't been [observerably] pushed to disk yet, these values don't have meaning.



> -----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 Saturday, 1 December 2012 01:52:19 UTC