W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2012

Re: [File API] File behavior under modification

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 11 Jul 2012 19:11:18 -0700
Message-ID: <CA+c2ei8Ej88CwOpZSFBkJ8W13ZC4P3QoZw7Y0VrmZ-sNUoCdVw@mail.gmail.com>
To: Glenn Maynard <glenn@zewt.org>
Cc: Arun Ranganathan <aranganathan@mozilla.com>, Eric U <ericu@google.com>, Web Applications Working Group WG <public-webapps@w3.org>, Kinuko Yasuda <kinuko@google.com>, Jian Li <jianli@google.com>, Alexey Proskuryakov <ap@webkit.org>, Satoru Takabayashi <satorux@google.com>, Toni Barzic <tbarzic@google.com>
On Wed, Jul 11, 2012 at 7:02 PM, Glenn Maynard <glenn@zewt.org> wrote:
> On Wed, Jul 11, 2012 at 2:53 PM, Arun Ranganathan <aranganathan@mozilla.com>
> wrote:
>> I agree that making snapshotting clearer might be a good idea.
>> It is true that reading size and lastModifiedDate are synchronous, but
>> this seemed a small trade-off compared to data reads.
>> My instinct is that an asynchronous API for mtime is overkill.
> All disk I/O needs to be asynchronous.


All APIs which generate File objects based on IO create the File
objects asynchronously. This to enable the implementation to get the
size and lastModification date asynchronously and then store it in the
File object.

For the rest of the lifetime of the File object these numbers
represent a snapshot. Hence to access the loastModifiedDate doesn't
require any IO. The implementation only needs to returned the saved

/ Jonas
Received on Thursday, 12 July 2012 02:12:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:37 UTC