On May 23, 2012, at 6:58 AM, Glenn Maynard <[email protected]> wrote: > On Wed, May 23, 2012 at 3:03 AM, Kinuko Yasuda <[email protected]> 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.
