dconf is a backend to GSettings, on platforms that don't already have configuration storage systems.
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 GDM configuration utility no longer have to be run as root.
Design
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).
dconf API
/! 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
* watching
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).
Tidak ada komentar:
Posting Komentar
Hanya manusia yang berkomentar baik dan sopan. sedangkan hanya binatang yang berkomentar buruk dan tidak memikirkan perasaan dan tidak menghargai orang lain... Trima kasih....