Re: [File API] File behavior under modification from Arun Ranganathan on 2012-07-11 (public-webapps@w3.org from July to September 2012)

From: Arun Ranganathan <aranganathan@mozilla.com>
Date: Wed, 11 Jul 2012 16:02:54 -0400
To: Glenn Maynard <glenn@zewt.org>
Cc: Kinuko Yasuda <kinuko@chromium.org>, Eric U <ericu@google.com>, 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>
Message-Id: <124C7210-655A-402A-A32F-FC2B64EF9E16@mozilla.com>

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 20:03:21 UTC