Re: Updates to FileAPI

On Tue, Dec 21, 2010 at 11:31 AM, Arun Ranganathan <arun@mozilla.com> wrote:
> I have updated the editor's draft of the  File API (special winter solstice
> edition).
>
> In particular:
>
> On 12/20/10 8:32 PM, Michael Nordman wrote:
>>
>> On Mon, Dec 20, 2010 at 4:08 PM, Arun Ranganathan<arun@mozilla.com>
>>  wrote:
>>>
>>> On 12/20/10 5:38 PM, Jian Li wrote:
>>>
>>> On Mon, Dec 20, 2010 at 2:10 PM, Ian Hickson<ian@hixie.ch>  wrote:
>>>>
>>>> On Mon, 20 Dec 2010, Arun Ranganathan wrote:
>>>>>
>>>>> http://dev.w3.org/2006/webapi/FileAPI/
>>>>>
>>>>> Notably:
>>>>>
>>>>> 1. lastModifiedDate returns a Date object.
>>>
>>> I think it makes more sense to return a new Date object each time. We
>>> have
>>> the same issue with Metadata.modificationTime.
>>>
>
> There are more rigid conformance requirements around lastModifiedDate.
>
> http://dev.w3.org/2006/webapi/FileAPI/#dfn-lastModifiedDate
>
> (Ensure that your previous copy has been flushed).
>
>
>> I think we have the expectation that any published URLs, that have not
>> been explicitly revoked earlier, are jetisoned at some well defined
>> document cleanup time... what hixie pointed to looks like a great
>> place...
>>
>> http://www.whatwg.org/specs/web-apps/current-work/complete.html#unloading-document-cleanup-steps
>>
> I've bolstered the lifetime conformance language with this:
> http://dev.w3.org/2006/webapi/FileAPI/#lifeTime
>
> The only nagging doubt I have about this proposal is that the creation and
> revocation methods (static) are on window.URL, but the actual Blob object
> has an affiliated document, which upon cleanup flushes the URLs affiliated
> with it.
>
> We still need to address nits about event queue, abort, and sequence<T>, but
> those will come in due course.


"When a user agent unloads a document, as part of the unloading
document cleanup steps, it MUST revoke a Blob URI which dereferences a
Blob object in that document. Implementations MUST ensure that a Blob
URI is revoked after URL.revokeObjectURL is called with that Blob URI
as an argument. Implementations MUST respond with a 404 Not Found if a
Blob URI is dereferenced after URL.revokeObjectURL is called on that
paticular Blob URI."

I don't know what "a Blob object in that document" means? That
language is a confusing to me.

The cleanup steps should revoke blob URIs that were created via a call
to the URL.createObjectURL from within that document.  Two different
documents (docA and docB) may create two different URLs (urlA and
urlB) for the same Blob. When docA is cleaned up, urlA should be
revoke but urlB should not.


> -- A*
>
>
>

Received on Tuesday, 21 December 2010 21:08:08 UTC