RE: revised recording proposal

If File inherits from Blob, and Blob is immutable, what does 'lastModifiedDate' mean?  Shouldn't it be the same thing as 'createdDate'?  

- Jim

-----Original Message-----
From: Travis Leithead [mailto:travis.leithead@microsoft.com] 
Sent: Friday, November 30, 2012 7:56 PM
To: Mandyam, Giridhar; Harald Alvestrand
Cc: public-media-capture@w3.org
Subject: 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:58:21 UTC