docs/dconf-overview.xml

   1 <?xml version='1.0'?>
   2 <!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
   3   "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
   4
   5 <refentry id="dconf-overview">
   6
   7   <refentryinfo>
   8     <title>dconf Overview</title>
   9     <productname>dconf</productname>
  10
  11     <authorgroup>
  12       <author>
  13         <contrib>Developer</contrib>
  14         <firstname>Ryan</firstname>
  15         <surname>Lortie</surname>
  16         <email>desrt@desrt.ca</email>
  17       </author>
  18     </authorgroup>
  19   </refentryinfo>
  20
  21   <refmeta>
  22     <refentrytitle>dconf</refentrytitle>
  23     <manvolnum>7</manvolnum>
  24     <refmiscinfo class="manual">Conventions and miscellaneous</refmiscinfo>
  25   </refmeta>
  26
  27   <refnamediv>
  28     <refname>dconf</refname>
  29     <refpurpose>A configuration system</refpurpose>
  30   </refnamediv>
  31
  32   <refsect1>
  33     <title>Description</title>
  34
  35     <para>
  36       dconf is a simple key/value storage system that is heavily optimised for reading.  This makes it an ideal
  37       system for storing user preferences (which are read 1000s of times for each time the user changes one).
  38       It was created with this usecase in mind.
  39     </para>
  40     <para>
  41       All preferences are stored in a single large binary file.  Layering of preferences is possible using
  42       multiple files (ie: for site defaults).  Lock-down is also supported.  The binary file for the defaults
  43       can optionally be compiled from a set of plain text keyfiles.
  44     </para>
  45     <para>
  46       dconf has a partial client/server architecture.  It uses D-Bus.  The server is only involved in writes
  47       (and is not activated in the user session until the user modifies a preference).  The service is stateless
  48       and can exit freely at any time (and is therefore robust against crashes).  The list of paths that each
  49       process is watching is stored within the D-Bus daemon itself (as D-Bus signal match rules).
  50     </para>
  51     <para>
  52       Reads are performed by direct access (via mmap) to the on-disk database which is essentially a hashtable.
  53       For this reason, dconf reads typically involve zero system calls and are comparable to a hashtable lookup
  54       in terms of speed.  Practically speaking, in simple non-layered setups, dconf is less than 10 times slower
  55       than GHashTable.
  56     </para>
  57     <para>
  58       Writes are assumed only to happen in response to explicit user interaction (like clicking on a checkbox in
  59       a preferences dialog) and are therefore not optimised at all.  On some file systems, dconf-service will
  60       call fsync() for every write, which can introduce a latency of up to 100ms.  This latency is hidden by the
  61       client libraries through a clever "fast" mechanism that records the outstanding changes locally (so they
  62       can be read back immediately) until the service signals that a write has completed.
  63     </para>
  64     <para>
  65       The binary database format that dconf uses by default is not suitable for use on NFS, where mmap does not
  66       work well. To handle this common use case, dconf can be configured to place its binary database in
  67       <envar>XDG_RUNTIME_DIR</envar> (which is guaranteed to be local, but non-persistent) and synchronize it
  68       with a plain text keyfile in the users home directory.
  69     </para>
  70   </refsect1>
  71
  72   <refsect1>
  73     <title>Profiles</title>
  74
  75     <para>
  76       A profile is a list of configuration databases that dconf consults to find the value for a key. The user's personal
  77       database always takes the highest priority, followed by the system databases in the order prescribed by the profile.
  78     </para>
  79
  80     <para>
  81       On startup, dconf consults the <envar>DCONF_PROFILE</envar> environment variable. If set, dconf will attempt to open
  82       the named profile, aborting if that fails. If the environment variable is not set, it will attempt to open the profile
  83       named "user" and if that fails, it will fall back to an internal hard-wired configuration. dconf stores its profiles
  84       in text files. <envar>DCONF_PROFILE</envar> can specify a relative path to a file in <filename>/etc/dconf/profile/</filename>,
  85       or an absolute path (such as in a user's home directory). The profile name can only use alphanumeric characters or '_'.
  86     </para>
  87
  88     <para>
  89       A profile file might look like the following:
  90       <screen>
  91 user-db:user
  92 system-db:local
  93 system-db:site
  94       </screen>
  95     </para>
  96
  97     <para>
  98       Each line in a profile specifies one dconf database. The first line indicates the database used to write changes, and the
  99       remaining lines indicate read-only databases. (The first line should specify a user-db or service-db, so that users can actually
 100       make configuration changes.)
 101     </para>
 102
 103     <para>
 104       A "user-db" line specifies a user database. These databases are found in <filename><envar>$XDG_CONFIG_HOME</envar>/dconf/</filename>.
 105       The name of the file to open in that directory is exactly as it is written in the profile. This file is expected to be in the binary
 106       dconf database format. Note that <envar>XDG_CONFIG_HOME</envar> cannot be set/modified per terminal or session, because then the writer
 107       and reader would be working on different DBs (the writer is started by DBus and cannot see that variable).
 108     </para>
 109
 110     <para>
 111       A "service-db" line instructs dconf to place the binary database file for the user database in <envar>XDG_RUNTIME_DIR</envar>.
 112       Since this location is not persistent, the rest of the line instructs dconf how to store the database persistently. A typical
 113       line is <literal>service-db:keyfile/user</literal>, which tells dconf to synchronize the binary database with a plain text
 114       keyfile in <filename><envar>$XDG_CONFIG_HOME</envar>/dconf/user.txt</filename>. The synchronization is bi-directional.
 115     </para>
 116
 117     <para>
 118       A "system-db" line specifies a system database. These databases are found in <filename>/etc/dconf/db/</filename>. Again, the name of
 119       the file to open in that directory is exactly as it is written in the profile and the file is expected to be in the dconf database
 120       format.
 121     </para>
 122
 123     <para>
 124       If the <envar>DCONF_PROFILE</envar> environment variable is unset and the "user" profile can not be opened, then the effect is as if
 125       the profile was specified by this file:
 126       <screen>
 127 user-db:user
 128       </screen>
 129       That is, the user's personal database is consulted and there are no system settings.
 130     </para>
 131   </refsect1>
 132
 133   <refsect1>
 134     <title>Key Files</title>
 135
 136     <para>
 137       To facilitate system configuration with a text editor, dconf can populate databases from plain text keyfiles. For any given system
 138       database, keyfiles can be placed into the <filename>/etc/dconf/db/<replaceable>database</replaceable>.d/</filename> directory. The
 139       keyfiles contain groups of settings as follows:
 140      </para>
 141      <screen>
 142 # Some useful default settings for our site
 143
 144 [system/proxy/http]
 145 host='172.16.0.1'
 146 enabled=true
 147
 148 [org/gnome/desktop/background]
 149 picture-uri='file:///usr/local/rupert-corp/company-wallpaper.jpeg'
 150      </screen>
 151      <para>
 152       After changing keyfiles, the database needs to be updated with the
 153       <citerefentry><refentrytitle>dconf</refentrytitle><manvolnum>1</manvolnum></citerefentry> tool.
 154     </para>
 155   </refsect1>
 156
 157   <refsect1>
 158     <title>Locks</title>
 159
 160     <para>
 161       System databases can contain 'locks' for keys. If a lock for a particular key or subpath is installed into a database
 162       then no database listed above that one in the profile will be able to modify any of the affected settings. This can be
 163       used to enforce mandatory settings.
 164     </para>
 165
 166     <para>
 167       To add locks to a database, place text files in the <filename>/etc/dconf/db/<replaceable>database</replaceable>.d/locks</filename>
 168       directory, where <replaceable>database</replaceable> is the name of a system database, as specified in the profile. The files
 169       contain list of keys to lock, on per line. Lines starting with a # are ignored. Here is an example:
 170     </para>
 171     <screen>
 172 # prevent changes to the company wallpaper
 173 /org/gnome/desktop/background/picture-uri
 174     </screen>
 175     <para>
 176       After changing locks, the database needs to be updated with the
 177       <citerefentry><refentrytitle>dconf</refentrytitle><manvolnum>1</manvolnum></citerefentry> tool.
 178     </para>
 179   </refsect1>
 180
 181   <refsect1>
 182     <title>Portability</title>
 183
 184     <para>
 185       dconf mostly targets Free Software operating systems.  It will theoretically run on Mac OS but there isn't
 186       much point to that (since Mac OS applications want to store preferences in plist files).  It is not
 187       possible to use dconf on Windows because of the inability to rename over a file that's still in use (which
 188       is what the dconf-service does on every write).
 189     </para>
 190   </refsect1>
 191
 192   <refsect1>
 193     <title>API stability</title>
 194
 195     <para>
 196       The dconf API is not particularly friendly, and is not guaranteed to be stable.  Because of this and the
 197       lack of portability, you almost certainly want to use some sort of wrapper API around it.  The wrapper API
 198       used by GTK+ and GNOME applications is
 199       <ulink url="http://developer.gnome.org/gio/stable/GSettings.html">GSettings</ulink>, which is included as
 200       part of GLib. GSettings has backends for Windows (using the registry) and Mac OS (using property lists) as
 201       well as its dconf backend and is the proper API to use for graphical applications.
 202     </para>
 203   </refsect1>
 204
 205   <refsect1>
 206     <title>See Also</title>
 207     <para>
 208       <citerefentry><refentrytitle>dconf-service</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
 209       <citerefentry><refentrytitle>dconf-editor</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
 210       <citerefentry><refentrytitle>dconf</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
 211       <ulink url="http://developer.gnome.org/gio/stable/GSettings.html">GSettings</ulink>
 212     </para>
 213   </refsect1>
 214 </refentry>