W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2012

Re: File modification

From: Charles Pritchard <chuck@jumis.com>
Date: Tue, 10 Jan 2012 13:57:24 -0800
Message-Id: <DAC2FBA1-E376-4B34-917D-8D54E2CCD2D8@jumis.com>
Cc: Charles Pritchard <chuck@visc.us>, "public-webapps@w3.org" <public-webapps@w3.org>
To: Eric U <ericu@google.com>




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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:49 GMT