Users can select a variety of data storage backends, such as XML text files, ACAP, or databases (LDAP, DB, etc.). This makes it easy to adapt GConf to local needs. It also avoids the age-old "text files vs. binary registry" debate. (Note: the current GConf only has an XML backend implemented, other backends are easy to write though.)

GConf offers a notification service, so applications can ask to be notified when the value of a key changes. This allows settings to be applied to groups of applications, without restarting them and without ugly hacks. It also allows a clean model-view architecture for applications.

Each user has a "GConf search path" which is a list of configuration sources to scan for each value. For example, the configuration engine might look for values first in the local machine's database and then in a network-wide database.

GConf is implemented as a per-user daemon, which makes locking a non-issue and allows aggressive caching.

The client API is simple and 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.