Re: File modification

I don't follow.  Either the user always has to poll the Entry to trigger
the event, or you never have to.  The former defeats the purpose of having
an event (optimized by OS change notifications, low-overhead and
instantaneous); the latter may not be possible (NFS).  You can't have a web
API where you only sometimes have to do something.

(I think CIFS does support change notifications, based on UI observations.
I wonder if this will show up in NFS.  I know that file changes show up
immediately in Windows file explorer windows over CIFS, but not NFS.)
On Jan 12, 2012 10:51 AM, "Charles Pritchard" <chuck@visc.us> wrote:

> 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.
>>
>>
>>
>>
>>