Re: proposed architecture evolutions for GConf

[Rodrigo Moya <rodrigo gnome-db org>]

On Sat, 2006-11-11 at 12:02 +0100, Josselin Mouette wrote:
> Hi,
> 
> being repeatedly faced with trouble about the GConf architecture, I've
> thought a bit about the global GConf situation, and I'm therefore
> proposing some improvements I'd like this to be discussed a bit before
> any code comes up. I'll try to summarize the current situation for those
> who don't know it and show my conclusions. I hope I won't be too much
> stating the obvious.
> 
> There are several ways to deal with a single-session, single-host
> configuration engine. Real problems arise when the user can log in
> several times on different machines, with a shared filesystem. With the
> number of corporate users working over NFS, this is not something we can
> ignore.
> 
> The current implementation communicates with gconfd using CORBA.
> However, by default it uses a local lock in /tmp/gconfd-$user and starts
> one daemon for each host. This has several major drawbacks:
>       * configuration changes are not notified to other hosts;
>       * worse, they are written on disk without locking and can end up
>         corrupted if two hosts write at the same moment;
>       * even worse, there is a trivial local denial of service attack
>         that consists in creating a /tmp/gconfd-$otheruser directory.
> 
> I think a good short-term change is to revert to global locking by
> default. Global locking is done in $HOME, avoiding the denial of service
> issue and proper write locking is implemented. As only one daemon is
> started, remote notification works. However, you need to tell ORBit to
> accept IP connections in this case, which is deactivated by default for
> obvious security reasons. There is already an explicit error message
> asking to enable this support, so I don't think there's anything more to
> do.
> 
> For a longer term, we can envision a new communication backend.
> Obviously, dbus comes to mind. Unfortunately, while it definitely brings
> some improvement for the single-host use, it is completely unsuitable
> for multiple host setups. And apart from dbus, I don't know of anything
> else that would give sufficient improvement over CORBA to justify the
> move.
> 
> 
> How about forgetting this communication thing? Configuration is stored
> in files, we just need to read and write these files. We even have some
> decent ways to monitor files now: local using inotify, remote using fam
> with dnotify.
> 
> To achieve this, the first thing to do - and it should have been done
> for a long time - is to move the file notification API from gnome-vfs to
> glib. To avoid introducing a new dependency, it would require to
> dlopen /usr/lib/libfam.so.0, or to dlopen a plugin linking to it,
> instead of linking to it directly. This GMonitor interface could then be
> used by various applications needing monitoring, like gnome-vfs,
> gnome-menus, evolution...
> 
> ... and GConf. If we move back again to a split-file backend for GConf,
> we can make libgconf directly read, write (with proper locking) and
> monitor these files, without any need for a daemon. If a migration
> script is provided, complete source and binary compatibility could be
> retained. The backend could use libxml as currently, or move to a
> GKeyFile implementation if someone really feels the need to integrate
> GConf into Glib.
> 
> It would also bring more consistency in how configuration is handled, as
> the freedesktop MIME information is already dealt up by the way of file
> monitoring.
> 
and what about other backends, like LDAP? I guess you could have code in
libgconf to monitor LDAP/whatever_other_backends databases, but not sure
how this would work
-- 
Rodrigo Moya <rodrigo gnome-db org>