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 <[EMAIL PROTECTED]>
_______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
