Elektrified X.org released (was: X configuration paradigm, and a proposal)

[Avery Pennarun]

On Sun, Dec 05, 2004 at 04:17:36PM -0300, Avi Alkalay wrote:

> Yeah I know.... I'll try to stick in the high level, but I'm worried
> about dependencies. It makes no sense to have /lib/libkdb.so depending
> on libs under /usr/lib.
> 
> The 5 minutes I spent reading about inotify made me believe it is a
> kernel module, but I couldn't find it, nor the /dev entry, nor the
> dmesg messages in the FC2 machine I have close to me right now. Is
> this stuff already included in regular distros kernels ?

Remember, all that matters right now is that the *API* of elektra be
compatible with any kind of smart notification mechanism.  That definitely
means you should be compatible with gamin, but make sure plain inotify and
FAM would work too... and don't forget about your plain polling, which is
actually a fine solution for certain kinds of daemons and a small number of
keys.

The actual polling implementation can be swapped out later, as I found out
when I wrote my UniConf backend.  The only problem is that the current API
*requires* polling, which isn't going to work well with programs using, say,
libevent.

My advice continues to be that you should support simple callback
registrations: call this function when this keyset changes.  Don't call this
function anymore when this keyset changes.  Poll for changes now and call
any registered events.  (And be aware that the "poll" function might not
*actually* be necessary in some implementations.)

Note: you also should look at recursive notifications.  I have lots of
programs that want to watch, for example, /system/users/*/password and be
told whenever anyone's password changes, so they can reconfigure
/etc/rsync.secrets or something.  The current system doesn't seem to lend
itself well to that at all.

Have fun,

Avery