- From: Arun Ranganathan <arun@mozilla.com>
- Date: Tue, 21 Dec 2010 14:31:00 -0500
- To: Michael Nordman <michaeln@google.com>
- CC: Jian Li <jianli@chromium.org>, Ian Hickson <ian@hixie.ch>, Eric Uhrhane <ericu@google.com>, Web Applications Working Group WG <public-webapps@w3.org>
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. -- A*
Received on Tuesday, 21 December 2010 19:31:40 UTC