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.
Comments anyone?
--
Josselin Mouette /\./\
"Do you have any more insane proposals for me?"
Attachment:
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=