dconf is a backend to GSettings, on platforms that don't already have configuration storage systems.
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 2 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).
/! 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 categorires:
* 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 writablity 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).
What's New in This Release: [ read full changelog ]
· Set G_LOG_DOMAIN so that 'dconf' shows in GLib log messages
· Brazilian Portuguese