- From: Charles Pritchard <chuck@jumis.com>
- Date: Tue, 10 Jan 2012 13:57:24 -0800
- To: Eric U <ericu@google.com>
- Cc: Charles Pritchard <chuck@visc.us>, "public-webapps@w3.org" <public-webapps@w3.org>
Received on Tuesday, 10 January 2012 21:57:57 UTC
On Jan 10, 2012, at 1:53 PM, Eric U <ericu@google.com> wrote: > On Tue, Jan 10, 2012 at 1:29 PM, Charles Pritchard <chuck@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.
Received on Tuesday, 10 January 2012 21:57:57 UTC