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