W3C home > Mailing lists > Public > public-device-apis@w3.org > October 2010

Re: Updates to FileAPI

From: Arun Ranganathan <arun@mozilla.com>
Date: Tue, 12 Oct 2010 14:18:43 -0400
Message-ID: <4CB4A683.7070509@mozilla.com>
To: Eric Uhrhane <ericu@google.com>
CC: Web Applications Working Group WG <public-webapps@w3.org>, Ian Hickson <ian@hixie.ch>, public-device-apis <public-device-apis@w3.org>
  On 10/12/10 2:12 PM, Eric Uhrhane wrote:
> Arun:
> On Tue, Oct 12, 2010 at 10:46 AM, Arun Ranganathan<arun@mozilla.com>  wrote:
>>   WebApps WG,
>> There have been some updates to the File API.
>> http://dev.w3.org/2006/webapi/FileAPI/
>> Notable changes are:
>> 1. Exception codes are no longer harnessed to DOMException's exception
>> codes, per discussion on this listserv.
>> 2. Metadata attributes creationDate and lastModifiedDate have been added to
>> the File object, per discussion on the WHATWG listserv.
> My apologies for not bringing this up earlier; I just realized that
> the discussions I've been involved with weren't on the public lists,
> and I didn't share their conclusions on the relevant threads.
> The creationDate is going to be problematic.  It works fine on
> Windows, but not on Unix-style systems.
> On Unix, ctime is *not* creation time.  It's the last time the inode
> was modified, so e.g. changing permission bits will alter it.
> http://en.wikipedia.org/wiki/MAC_times has a good writeup on ctime.
> I see that your spec allows for an empty string on systems where
> creationDate isn't available, but my gut response is not to add a
> Windows-specific feature.

(Yes, this discussion also occurred on WHATWG).

Is your suggestion to *only* allow lastModifiedDate, and not to support 
creationDate at all, even though implementations can return the empty 
string on [Unix-style] systems where creationDate is unreliable?

>> 3. Blob no longer has a .url attribute.  Instead, Window and
>> WorkerGlobalScope have been extended with methods createBlobURL and
>> revokeBlobURL, per discussion on this listserv.
>> 4. The Blob URI section has undergone changes, per discussion on this
>> listserv.  Notably, Blob supports the addition of an HTTP Content-Type,
>> which implementations must return as a response header when Blob URIs are
>> dereferenced.
>> 5. There are (ongoing) fixes to bugs, including incorrect uses of long long
>> (in lieu of unsigned long long), per (ongoing) discussion on the listserv.
> I'll update my specs to use unsigned long long where appropriate as well.
> I'll also be updating my extensions to FileError/FileException.  Shall
> I leave a gap, or just start numbering where you left off?

I think you can probably start where what's in File API leaves off.  We 
should keep tightly in sync :-)

-- A*
Received on Tuesday, 12 October 2010 18:19:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:23 UTC