Re: Updates to FileAPI

On 12/21/10 4:07 PM, Michael Nordman wrote:
> 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.

Both you and Ian make good nits about redundant conformance requirements 
as well as per-document cleanup.  I'll take both nits into consideration 
and cleanup the spec. text.

-- A*

Received on Tuesday, 21 December 2010 22:04:39 UTC