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.