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<a...@mozilla.com> wrote:
On 12/20/10 5:38 PM, Jian Li wrote:
On Mon, Dec 20, 2010 at 2:10 PM, Ian Hickson<i...@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*
