Re: Updates to FileAPI

On Mon, Oct 18, 2010 at 12:37 PM, Arun Ranganathan <arun@mozilla.com> wrote:
>  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).

Yeah, I just don't see any efficient way of getting around that.  And
at least you *can* write code that'll work on any platform--you just
have to be aware of the issues.  And libraries can be written that'll
wrap ArrayBuffers and take care of it for you, if that turns out to be
useful.

Thanks for the update.

    Eric

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