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:21:29 UTC