Re: making FAM a required dependency

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


Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]