- From: Eric Uhrhane <ericu@google.com>
- Date: Tue, 12 Oct 2010 11:24:11 -0700
- To: arun@mozilla.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 Tue, Oct 12, 2010 at 11:18 AM, Arun Ranganathan <arun@mozilla.com> wrote: > 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). Well, there was discussion in May about how modificationDate might be earlier than creationDate on Windows, due to odd copy behavior, but no mention IIRC that this couldn't work at all on Unix systems, which I think is significant. > 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? Yes. If we publish APIs that only work on Windows, Windows-based developers will write code that works on their test machines, but fails elsewhere. Web code is supposed to be more portable than that. >>> 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 :-) Sounds good; thanks.
Received on Tuesday, 12 October 2010 18:26:53 UTC