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

Re: File modification

From: Glenn Maynard <glenn@zewt.org>
Date: Thu, 12 Jan 2012 13:20:54 -0500
Message-ID: <CABirCh_NM09382Dw3kN-wt1mNQLmoPX8+dtK5ObRRZgk0fBPmw@mail.gmail.com>
To: Charles Pritchard <chuck@jumis.com>
Cc: Charles Pritchard <chuck@visc.us>, "public-webapps@w3.org" <public-webapps@w3.org>, Eric U <ericu@google.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:30 UTC