- From: Michael Nordman <michaeln@google.com>
- Date: Mon, 20 Dec 2010 17:32:18 -0800
- To: arun@mozilla.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>
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. >> >> You don't have a conformance requirement for returning a Date object. (The >> only MUST is for the case of the UA not being able to return the >> information.) I mention this because for attributes that return >> objects, it's important to specify whether the same object is returned >> each time or whether it's a new object that is created each time. >> Presumably for a Date object you want to require a new object be created >> each time. > > I think it makes more sense to return a new Date object each time. We have > the same issue with Metadata.modificationTime. > > I agree with Ian and Jian Li that it makes sense to return a new Date > object, and we should have conformance language about this. I'll fix this > very shortly. > >> >> >> > 2. We use the URL object and expose static methods on it for Blob URI >> > creation and revocation. >> >> Looks good to me. FYI, I'm probably going to be extending this mechanism >> for Streams in due course. I expect I'll bring this up again in due course >> so we can work out how to make sure the specs don't step on each other. >> >> I'm a little concerned about the lifetime of these URLs potentially >> exposing GC behaviour -- we've tried really hard not to expose GC >> behaviour in the past, for good reason. Can't we jetison the URLs as part >> of the unloading document cleanup steps? >> >> >> http://www.whatwg.org/specs/web-apps/current-work/complete.html#unloading-document-cleanup-steps >> >> (Note that Window objects in some edge cases can survive their Document.) >> > > Hmm... in the past on this issue, attempts to determine *when exactly* the > URLs were jetisoned weren't successful (and hence we have an explicit > revocation method). There's a long-ish thread on this very topic on this > listserv. > > I *suppose* we can harness this to document cleanup steps, but I'm > interested to hear from others. 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 >> >> > Also, I've minuted Sam Weinig at TPAC saying he'd prefer us to roll back >> > from using the sequence<T> type WebIDL syntax to index getters. Sam: >> > are you still tightly wed to this? WebIDL has undergone changes since >> > last we spoke. I'm copying what HTML5 is doing, and didn't want to be >> > inconsistent in rolling this back. >> >> FWIW, IIRC the HTML spec is a bit out of sync when it comes to WebIDL. >> > > I think that sequence<T> is syntactically desirable, but I'm not sure > present WebIDL accounts for *.index() behavior, which could be why Sam wants > to roll back. > > -- A* >
Received on Tuesday, 21 December 2010 01:32:51 UTC