On Mon, 2002-09-30 at 15:57, Jeff Waugh wrote: > 3) dnotify (and other OS-specific notification schemes) support in the > to-be-written gnome-vfs daemon, or just add dnotify support to gnome-vfs > without the daemon (which might suck). dnotify is awful. It uses signals for callbacks. This sucks badly to integrate into the glib mainloop and gnome-vfs's threaded async system. What you end up needing is an external program to catch the signals and then send notifications across a file descriptor. We could call this program "fam"... But yeah, if/when we have a gnome-vfs-daemon (which will happen when more than two people agree what it should do, if it should exist and what its lifecycle should be) implementing dnotify and polling based notification in that would make sense. On Tue, 2002-10-01 at 02:05, Alexander Larsson wrote: > As a maintainer of FAM in Red Hat i must say i don't like this. FAM is a > fraigile and crappy piece of code. It has various unwanted dependencies > and is prone to failure. I've long wanted to do some sort rewrite that > was more desktop-oriented, but i've never had time. > You're effectively the FAM maintainer on Linux as far as I can tell :) It does seem crappy but it has the advantage of being quite old code. Its been used actively on IRIX for a long long time > Do we really need to provide non-optional monitoring in gnome-vfs? It will > always be optional for non-local filesystems anyway. I see file > notification as a nice extra, but given its issues its something I do not > want us to rely on. The way I've treated the API is that you're asking GnomeVFS "please tell me about modifications to this URI if you happen to find out about them". Ian
Attachment:
signature.asc
Description: This is a digitally signed message part