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

Re: [File API] File behavior under modification

From: Eric U <ericu@google.com>
Date: Wed, 11 Jul 2012 15:41:26 -0700
Message-ID: <CAHvSExe=37YKwYVdtBua3LCiC=U=Zqim73D-t98q9G0uNgLFHA@mail.gmail.com>
To: Arun Ranganathan <aranganathan@mozilla.com>
Cc: Glenn Maynard <glenn@zewt.org>, Kinuko Yasuda <kinuko@chromium.org>, Web Applications Working Group WG <public-webapps@w3.org>, Jonas Sicking <jonas@sicking.cc>, 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 1:02 PM, Arun Ranganathan
<aranganathan@mozilla.com> wrote:
> On May 23, 2012, at 9:58 AM, Glenn Maynard wrote:
> On Wed, May 23, 2012 at 3:03 AM, Kinuko Yasuda <kinuko@chromium.org> wrote:
>> Just to make sure, I assume 'the underlying storage' includes memory.
> Right.  For simple Blobs without a mutable backing store, all of this
> essentially optimizes away.
>> We should also make it clear whether .size and .lastModifiedDate should
>> return live state or should just returning the same constant values.  (I
>> assume the latter)
> It would be the values at the time of the snapshot state.  (I doubt it was
> ever actually intended that lastModifiedDate always return the file's latest
> mtime.  We'll find out when one of the editors gets around to this
> thread...)
> I think the ideal behavior is that it reflects values at snapshot state, but
> that reads if snapshot state has modified fail.
> -- A*
Received on Wednesday, 11 July 2012 22:42:09 UTC

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