W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2012

Re: [File API] File behavior under modification

From: Charles Pritchard <chuck@jumis.com>
Date: Wed, 23 May 2012 10:57:23 -0700
Message-Id: <53069094-0B0A-4274-8DE4-C7D7657FC26A@jumis.com>
Cc: Kinuko Yasuda <kinuko@chromium.org>, Eric U <ericu@google.com>, Web Applications Working Group WG <public-webapps@w3.org>, Arun Ranganathan <aranganathan@mozilla.com>, 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>
To: Glenn Maynard <glenn@zewt.org>
On May 23, 2012, at 6:58 AM, Glenn Maynard <glenn@zewt.org> 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 can't imagine that Mozilla's behavior here is intended. Only by returning a live mtime can authors be aware of whether or not the file has changed from a previous state.

We did go through this discussion quite awhile ago when I recommended file watcher hooks (which are available on engines like node.js).

It seems like there's a split between the ideal (take an immutable snapshot of the file) and the real world, where the File object represents an entry, such as FileEntry, not a static blob of data.

I think that's where the spec writing for this is challenging. I'd lean toward documenting what's really out there instead of mandating snapshot capabilities in the file system.
Received on Wednesday, 23 May 2012 17:57:58 UTC

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