Implementation Overview

Keys and Values

GConf is not a full-blown database by any means. It stores simple key-value pairs. This keeps the implementation simple and efficient. In particular, the following database features are not currently implemented:

• Queries

• Efficient storage of large chunks of data (such as entire documents)

• Transactions

Applications that require these sophisticated features should use LDAP or a full-scale database. Transactions may be added eventually, and are currently in the API in the form of the GConfChangeSet object, but for now change sets are not stored atomically.

A GConf key looks like a UNIX filename. Keys are organized into "directories" just as UNIX files are. For example, the /desktop directory stores desktop settings, and the hypothetical key /desktop/standard/background-color might store the color of the desktop background. The GConf documentation establishes a number of conventional directory names; you should follow the guidelines in the documentation when naming your application keys.

Values have types; the primitive types are integers, booleans, strings, and floating point numbers. Also, lists and pairs of primitive types are possible. Recursive types (list of list) are not permitted. Types have no size restriction; strings can be as long as you like, though unreasonably large strings (such as an entire XML document) will cause performance problems.

Configuration Server

GConf is implemented as a per-user daemon called gconfd. gconfd actually accesses the user's configuration backends by dynamically loading the appropriate backend modules. gconfd is also in charge of sending out notifications to interested applications when configuration values are modified.

One gconfd should exist per user at any given time. If a user logs in to two machines simultaneously, gconfd will run on the first machine, and the second machine will access it over the network.

gconfd talks to applications using CORBA as a transport. This is purely an implementation detail; a custom protocol over sockets could have been used or could be used in the future. Directly accessing the CORBA interface is not supported. Application programmers do not see CORBA while using GConf.

In general, gconfd is not visible to the application programmer. It is automatically launched as required. (Internally, the OAF object activation framework is used to obtain an object reference for the gconfd CORBA server.)

Because all database access goes via gconfd, locking is not really an issue. gconfd also aggressively caches configuration values, because all applications can share the same cache.

Schemas

In addition to the primitive types mentioned earlier (integer, string, etc.) the GConf database can store a schema. A schema is a description of a key; it includes a short description of the key, a longer documentation paragraph, the type of the key, a default value for the key, and the name of the application owning the key. Schemas are primarily intended for use by a regedit-style tool; such a tool can display the documentation for a key, and validate the type of any values you enter for the key.

Because schemas are simply values in the database, they can be referenced by key name. Conventionally, all schemas are below the /schemas toplevel directory.

Applications come with a special schema file which encodes the schema information in a human-editable text format. When the application is installed, the gconftool program shipped with GConf is used to insert the schema information into the GConf database. Also, all applications should install their schema file to a system-wide directory (specified in the GConf documentation). This allows system administrators to re-install all schemas into a different GConf backend with a single command (something like gconftool --install-schema-file /etc/gconf/schemas/*).