dconf
 | |
|
A screenshot of dconf Editor 0.20.0 running under Ubuntu MATE | |
| Developer(s) | The GNOME Project (Ryan Lortie) |
|---|---|
| Initial release | September 16, 2009 |
| Stable release | 0.24.0 / March 23, 2015[1] |
| Preview release | 0.25.1 / December 16, 2015[2] |
| Written in | C |
| Type | Configuration, settings management |
| License | GNU Lesser General Public License |
| Website |
wiki |
dconf is a low-level configuration system and settings management. Its main purpose is to provide a back-end to GSettings and KSettings on platforms that don't already have configuration storage systems. It depends on GLib. It is part of GNOME 3 and is a replacement for GConf.
Overview
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 GNOME Display Manager (GDM) configuration utility no longer have to be run as root.
Software architecture
Since a typical GNOME login consists of thousands of reads and ideally 0 writes, dconf is optimized 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 I/O 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 optimized—they traverse the bus and are handled by a "writer" -- a D-Bus 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 synchronize 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 D-Bus signal watch/match list).
Documentation
A system administrators guide for dconf is available. Since version 0.2, dconf is licensed under the LGPL version 2.1 "or later".
References
External links
- https://wiki.gnome.org/Projects/dconf
- https://download.gnome.org/sources/dconf/
- https://git.gnome.org/browse/dconf/
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
