Re: Updates to FileAPI

  On 10/12/10 2:24 PM, Eric Uhrhane wrote:
> 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.

Eric: I agree with this, so I'll strike creationDate as an attribute on 
File objects.

(FWIW, though, the fact that we return ArrayBuffer objects on file 
reads, which allows for endian considerations, means that we already 
allow a back door for platform specific code).

-- A*

Received on Monday, 18 October 2010 19:38:04 UTC