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

Re: [File API] File behavior under modification

From: Arun Ranganathan <aranganathan@mozilla.com>
Date: Wed, 11 Jul 2012 16:02:54 -0400
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>
To: Glenn Maynard <glenn@zewt.org>

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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:53 GMT