Re: File modification

You're at the mercy of many types of latency with web apps.

For the high-importance notepad case, you're talking about one file. I can poll every second from my web app and back off when the screen is idle, with current code in Chrome. Hooking into OS level file notification would give better results, and help me back off the polling. And if it's on NFS, and there's no update signal, looping through FileList would still get me my event.

NFS and thousands of files are an extreme case. But they can be managed and an update event would improve that management.

-Charles



On Jan 12, 2012, at 10:20 AM, Glenn Maynard <glenn@zewt.org> wrote:

> That's not good enough for many use cases.  For example, a notepad app that saves to disk wants to update the display if another program modifies the file.  You don't want that to be delayed until you scan the directory; you want the event pushed at you immediately  when it happens.  This is how I imagine most use cases looking.
> 
> On Jan 12, 2012 10:16 AM, "Charles Pritchard" <chuck@jumis.com> wrote:
> On 1/12/2012 6:34 AM, Glenn Maynard wrote:
> 
> Side-effects of event registration are outside of the DOM event model.  UAs can do whatever transparent optimizations they want, of course, but  APIs shouldn't *depend* on that for efficient implementations.
> 
> Occasional polling definitely has significant overhead (directories may have tens of thousands of files, be on network shares, etc), and should be widely avoided.
> 
> I also wonder whether change notifications work over eg. NFS.  It would be bad if this feature only sometimes worked (especially if it breaks on major but less used configurations like NFS), since once deployed, apps will be designed around it.
> 
> 
> On NFS and directories where directory notification is not available: send an onchanged event to FileList when an underlying File object changes upon access of its entry in FileList.
> 
> That is... as I'm looping through FileList grabbing files, it may invalidate a File object. FileList has now "changed".
> I won't know until the next event loop. That's good enough.
> 
> 
> 
> 

Received on Thursday, 12 January 2012 18:52:19 UTC