Re: Updates to FileAPI

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