Havoc Pennington and GConf

Havoc has been a GNOME hacker for a loooong time, with far too many outstanding hacks to his name. He wrote GTK+/GNOME Application Development, which is still widely regarded as the beginning GNOME hacker's bible, and chairs the GNOME Foundation Board of Directors. Havoc currently works at Red Hat, and very infrequently posts updates to the RHAD Labs news page.

GConf first appeared in GNOME 1.4, used by applications such as Nautlius and Galeon. It will be utilised across the entire GNOME 2.0 platform.

For anyone who hasn't encountered GConf before, please explain what it is, and how it fits in with GNOME 2.0.

There's an old feature article on this at developer.gnome.org

For people too lazy to read all that... here are the problems we needed to solve that the .ini-style text files in ~/.gnome did not address:

Key problem: We have apps made of multiple processes (components), and config settings used by multiple apps (e.g. desktop background, or two instances of the same app running on two displays or just twice on one display). This creates the following issues:

  1. locking; the .ini files have no locking, so break when two processes write to them at once
  2. keeping defaults in sync between apps. because apps hardcode the default settings inside the app, changing e.g. the default background involved changing two or three places in the control center, and somewhere in Nautilus, and so on. This gave rise to quite a few bugs.
  3. keeping current settings in sync between apps. This requires custom hacks; for example, if you change the GTK theme there is a semi-elaborate hack to notify all apps of the change. With gconf you get this for free.

Additional problems with the .ini files:

So GConf is two separate things. In the first place, it's an abstract API that allows us to resolve all these issues behind the scenes without having to change applications. In the second place, it's an evolving initial implementation of this API which uses CORBA, a userspace daemon, and XML files in your home directory.

How far along is the port to the GNOME 2.0 platform?

It's been compiling for a long time, since GLib and ORBit really did not change their API much. (Well, they added features but didn't break old ones.) There is one more change I want to make, which is to move away from bonobo-activation for launching gconfd; this will allow interoperability between the gconf 2.0 daemon and 1.0 clients, and will also make things more robust, I hope. I want to do this next week. We'll see. ;-)

GConf uses a number of GNOME 2.0 platform libraries, such as glib and libxml. Are there any features that you have enjoyed working with in particular, or that have made development easier?

It's hard to imagine writing C without using GLib, especially with GLib 2.0. Enjoyable as always.

The GError feature in GLib 2.0 actually originated in GConf, and was migrated to GLib. This is why GConf has decent error reporting. It turns out that this has its bad side, though; people think your software is more stable if you never print any errors. ;-) Then they don't know you were involved in their nonworking system!

Seriously, on the down side most of the errors are pretty cryptic. They help me a lot when I get a bug report, but they also confuse people and lead them to file bug reports about things that aren't bugs.

With libxml, I used it in a boneheaded way; I should have used the SAX API instead of the DOM. This made my life a lot more complicated. But, live and learn.

Did you have any big goals for the GNOME 2.0 version of GConf, beyond porting? How close are you to achieving those?

I didn't, my goal is to keep it stable. With the help of the Galeon team we've been making it Just Work out of the box, before you had to do some futzing with config files after installing GConf. Also, I want to do more in the robustness area.

The features I have in mind longer-term are mostly too ambitious for the GNOME 2 timescale. We need:

Those are probably the highest priorities.

Are there any areas that new hackers could help out with? Have any new hackers already been working on GConf that you'd like to plug?

I think the GUI admin tool is probably the easiest place to get started. There's already a gconf-editor module in CVS where someone started on this, but I think it needs some care and feeding. This could be a really useful feature for sysadmins and advanced users.

In the meantime there's also the gconftool command line app for modifying/querying the config database.

I've had lots of help from a couple guys at Sun (Colm, Tomas), several Galeon hackers, etc. in making GConf nice.

GConf is often compared to the Windows Registry - even the README file mentions it. How does GConf avoid the problems associated with the registry? Does it provide any significant features beyond it?

GConf is actually very different in design goals and implementation. The point in common is that it's essentially a big hash table, where you can store configuration data. However, it is different in the following ways:

Also, we should keep in mind that the part of GConf we're committed to is really just an API - an abstract way to get/set values. The XML files, the userspace daemon, etc. are just a first cut at implementation.

If we can get decent file change notification working - e.g. using FAM - we could actually dump the whole daemon thing, and just have each gconf client write directly to files, doing locking with fcntl() and detecting changes with FAM. But not a GNOME 2 change I don't think.

How does GConf handle the separation between user's personal configuration data, system configuration data set by the system administrator or distributor, and defaults set by the application developer?

GConf essentially has a "search path" for each setting. (It can be configured to have a different path for different areas of the configuration namespace, Colm added this feature.)

So GConf could look first in a read-only database of systemwide mandatory settings, then in a user's read-write homedir database, then in the system default database maintained by the sysadmin, then finally it would use the default from the schema file installed by the application developer.

Does GConf handle permissions? For exmaple, settings that the system administrator would prefer to make unchangeable by users?

Settings in a read-only source at the front of the config path are not modifiable by users. This is just "advisory" not "secure," that is, someone who knew how to program could easily manage to hack apps so they ignored the read-only source. The intent is to keep naive users from hosing settings that the sysadmin considers important to lock down.

Sun recently contributed a Berkeley DB backend for GConf. Are other backends currently in development?

There's been some work on an LDAP backend, and some discussion of an ACAP backend.

I think ACAP would be pretty cool - ACAP is close to GConf in some ways, but is more for "roaming data" such as your address book, while GConf isn't really designed to store data.

An interesting direction would be to get a nice ACAP server running for roaming data - the challenging part is to figure out how to do the UI so people can figure it out - and then piggyback GConf on that, so that apps using the GConf API would end up using ACAP on the backend.

What I'd envision is that on login you could specify an ACAP URI, and your preferences and data would be downloaded to replace the configuration stored locally on the system you're logging into.

This is really hard to get right, though.

LDAP has the advantage that many sites already have large LDAP deployments. The issue with LDAP is that it's a database-like structure, and GConf is a filesystem-style structure. It's hard for me to imagine how to store the GConf "database" in a real database in a way that would make sense to someone using LDAP directly to modify keys/values. But on the other hand I'm pretty ignorant of LDAP.

What kind of enhancements are in store for developers using or moving to GConf, now that it is an integral part of the GNOME platform?

GConf makes preferences code much more manageable, since it eliminates the issue of synchronization between apps and processes and even various portions of the same process. Also, something like George's PonG - automatically generating a prefs dialog tied to GConf keys - is pretty nice. It needs to be integrated into Glade somehow to be really useful.

What kind of enhancements are in store for administrators and users of GNOME 2.0 with GConf?

For users the big benefit is dynamic, instantaneous update of all apps when a preference is modified; i.e., it gives us instant-apply for prefs dialogs for free, even if the setting affects many processes.

Oh, also GConf will hopefully help out with the issue of running multiple GNOME sessions sharing a home directory. There's more work to be done here though. Right now it wouldn't work so well out-of-the-box because we disable CORBA connections over TCP by default, for example.

The biggest win is probably for sysadmins, although that won't be fully realized until we have the admin tool and some backend that's really scalable for being shared between multiple machines.

Anyhow, I think the main step forward for GNOME 2 will be getting some wide usage of the GConf API in GNOME applications. Then enhancements to the backend will be much more interesting, since more apps will be affected. So I'd like to see apps porting to use GConf, and in particular I'd like to see us installing schema files describing all config keys.

Thanks very much for your work on GConf and GNOME 2.0, Havoc!

Documentation Introduction to the GConf library
Tarballs ftp://ftp.gnome.org/pub/GNOME/earthquake/sources/gconf/
CVS module gconf, GNOME CVS
Gnotices Thread http://news.gnome.org/1000724741/index_html