(Pardon the top-quoting and poor editing; working off a phone today.) This isn't properly specced anywhere and may be impossible to implement perfectly, but previous discussions indicated that Chrome, at least, wanted File objects loaded from input elements to only represent access for the file as it is when the user opened it. That is, the File is immutable (like a Blob), and if the underlying OS file changes (thus making the original data no longer available), attempting to read the File would fail. (This was in the context of storing File in structured clone persistent storage, like IndexedDB.)
(I don't know if this was thought to apply to FSAPI-acquired Files as well, eg. requiring the user to request a new File from the Entry after modifying it. That would be annoying, but it would preserve the invariant that Blobs are immutable, which shouldn't be sacrificed lightly.) That would make onchanged not meaningful for File. However, it would be useful on Entry instead. I have one major technical concern: monitoring files for changes isn't free. With only a DOM event, all instantiated Files (or Entries) would have to monitor changes; you don't want to depend on "do something if an event handler is registered", since that violates the principle of event handler registration having no other side-effects. Monitoring should be enabled explicitly. I also wonder whether this could be implemented everywhere, eg. on mobile systems. On Jan 10, 2012 1:58 PM, "Charles Pritchard" <ch...@jumis.com> wrote: > > > > > On Jan 10, 2012, at 1:53 PM, Eric U <er...@google.com> wrote: > > On Tue, Jan 10, 2012 at 1:29 PM, Charles Pritchard <ch...@visc.us> wrote: > > Modern operating systems have efficient mechanisms to send a signal when a > watched file or directory is modified. > > > File and FileEntry have a last modified date-- currently we must poll > entries to see if the modification date changes. That works completely fine > in practice, but it doesn't give us a chance to exploit the efficiency of > some operating systems in notifying applications about file updates. > > > So as a strawman: a File.onupdated event handler may be useful. > > > It seems like it would be most useful if the File or FileEntry points > to a file outside the sandbox defined by the FileSystem spec. Does > any browser currently supply such a thing? Chrome currently > implements this [with FileEntry] only for ChromeOS components that are > implemented as extensions. Does any browser let you have a File > outside the sandbox *and* update its modification time? > > If you're dealing only with FileEntries inside the sandbox, there are > already more efficient ways to tell yourself that you've changed > something. > > > Far as I can tell, File is live, and it's supposed to be live from <input > type=file>. > > For FileEntry-- I'd imagine we'll see cross-origin communication with the > objects at some point. In those cases, onupdated would be simpler than an > additional postMessage layer for update notifications. >
