dconf is a low-level configuration system. Its main purpose is to provide a backend to GSettings on platforms that don't already have configuration storage systems.
November 19, 2012: dconf 0.15.2 released
October 26, 2011: dconf 0.11.0 released
September 27, 2011: dconf 0.10.0 released
September 19, 2011: dconf 0.9.1 released
July 26, 2011: dconf 0.9.0 released
July 26, 2011: dconf 0.8.0 released
May 9, 2011: dconf 0.7.5 released
May 6, 2011: dconf 0.7.4 released
March 22, 2011: dconf 0.7.3 released
February 5, 2011: dconf 0.7.2 released
January 18, 2011: dconf 0.7.1 released
January 18, 2011: dconf 0.7 released
December 21, 2010: dconf 0.6 released
August 4, 2010: dconf 0.5 released
July 14, 2010: dconf 0.4.2 released
June 25, 2010: dconf 0.4.1 released
June 11, 2010: dconf 0.4 released
May 25, 2010: dconf 0.3.1 released
October 27, 2009: dconf 0.2.1 released
October 7, 2009: dconf 0.2 released
September 17, 2009: dconf 0.1.1 released
September 16, 2009: dconf 0.1 released
dconf is a simple key-based configuration system. Keys exist in an unstructured database (but it is intended that keys that logically belong together are grouped together).
Change notification is supported.
Stacking of multiple configuration sources is supported. Mandatory keys are supported.
The stacking can be done at "mount points". For example, the global system configuration can be mounted under /system/ inside of each user's configuration space. A single configuration source may appear at multiple points in the hierarchy. For example, in addition to stacking over the normal keys at /user/, the system default keys may also appear at /default/ for inspection and modification by a system policy configuration utility.
PolicyKit integration is planned so that a normal user may temporarily gain the ability to, for example, write to the keys under /system/ (or /default/). This means that programs like the GDM configuration utility no longer have to be run as root.
Since a typical GNOME login consists of thousands of reads and ideally 0 writes, dconf is optimised for reads. Typically, reading a key from dconf involves zero system calls and zero context switches. This is achieved with a simple file format that doubles both as the storage format for data in dconf and as an IPC mechanism between the clients and the server.
Avoiding round trips and context switches is nice in itself, but the real win comes from allowing the IO scheduler in the kernel to do a better job by saturating it with requests coming from all of the applications trying to read their keys (as opposed to a common configuration server serially requesting a single key at a time).
Having all of the keys in a single compact binary format also avoids the intense fragmentation problems currently experienced by the tree-of-directories-of-xml-files approach.
Writes are less optimised -- they traverse the bus and are handled by a "writer" -- a DBus service -- in the ordinary way. Change notification is also handled by the writer. The reason for having a bus service at all is that because getting the clients to synchronise on writing would be a nightmare.
The writer service doesn't have to be activated until the first write operation is performed.
The service is completely stateless and can come and go as it pleases. The list of change notifications that an individual client is interested in is maintained by the bus daemon (as a dbus signal watch/match list).
A system administrators guide for dconf is available.
Note: Most applications will not want to interface directly with dconf, but rather with GSettings.
The dconf API is very simple and small. It can be roughly divided into 4 categories:
- utility functions
- database read functions
- database write functions
The read functions allow you to list the contents of the database, to read values, and to query the writability of a particular portion of the database (ie: according to system policy). Due to the database being mapped into each process's address space, these calls are synchronous and non-blocking.
The write functions allow you to set keys (including atomic multi-key writes), to reset keys and to apply locks (ie: policy). These calls all exist in two flavours: blocking synchronous versions and non-blocking asynchronous versions with an API style similar to that used in GIO.
The watching functions allow you to express interest in modifications to certain portions of the tree (or single keys).
Since version 0.2, dconf is licensed under the LGPL version 2.1 "or later".
Releases can be found on /Release
There is an Ubuntu PPA with up to date packages.
Development is happening in git://git.gnome.org/dconf and can be viewed here.
You can check out the current development snapshot using:
git clone git://git.gnome.org/dconf
or, if you have an account on gnome.org:
git clone ssh://<username>@git.gnome.org/git/dconf
Ryan Lortie <email@example.com>