Introduction: What is GConf?

GConf is a configuration data storage mechanism scheduled to ship with GNOME 2.0. GConf does work without GNOME however; it can be used with plain GTK+, Xlib, KDE, or even text mode applications as well. As of March 2000, there is no stable release of GConf yet, but the library is feature-complete.

The GNOME desktop is currently in the Windows 3.1 era with respect to application configuration data; applications store their configuration in flat .INI-style files. Windows later introduced a more sophisticated solution, the Registry. However, the Registry still has a number of shortcomings:

• It's very difficult to manage a large number of computers; system administrators can't install defaults, or push changes out to multiple user computers. Proprietary add-on tools exist that try to resolve this problem in various (rather frightening) ways.

• The registry contains lots of undocumented, cryptically-formatted data, and regedit is therefore dangerous and difficult to use.

• The registry becomes corrupted, and this tends to destroy the whole operating system installation.

GConf attempts to leapfrog the registry concept. It's a library which provides a simple configuration data storage interface to applications, and also an architecture that tries to make things easy for system administrators.

Here are some of the features of GConf:

• Replaceable backend architecture. GConf currently has a single backend that stores configuration data in XML-format text files; however, the architecture allows a Registry-like binary database backend, an LDAP backend, or even a full-blown SQL database backend. The backend used is configurable by the system administrator. This is a valuable feature for IS deparatments managing large numbers of computers.

• Configuration key documentation. Applications can install documentation along with their configuration data, explaining the possible settings and the effect of each configuration key. A regedit-style tool can display this documentation, making it much easier to customize applications without breaking them. The GConf database also stores useful meta-information such as the application that owns a key, when the key was last changed, etc.

• Data change notification service. If configuration data is changed, all interested applications are notified. The notification service works across the network, affecting all login sessions for a single user.

  This means that programs built from components (where each component may be in a separate process) are much easier to write, because if one component changes a setting the others can discover the change and update themselves. For example, GNOME's new Nautilus file manager is actually a collection of applications, including an embedded web browser, and various navigation components. The components communicate via CORBA. However, you want a single preferences dialog located in the top-level "shell" component. Without GConf, a custom protocol would have to be invented for each preferences setting, to notify embedded components of changes to user preferences.

  Notification is also useful if multiple application instances are running. GNOME 2.0 uses this feature to let user interface configuration take effect on-the-fly without restarting any applications; if you turn off toolbar icons, for example, toolbar icons will immediately disappear in all running apps.

• The client API is very abstract, which allows us to change its implementation at a later time without a big headache. Because a good implementation is a complex problem, this is important. I also like to think the API is simple to use.

• GConf does proper locking so that the configuration data doesn't get corrupted when multiple applications try to use it.