- default backend
One important aspect of a configuration library is the out-of-the-box
experience. How does the system work before anything is configured? The
optimal situation is that everything works fully, and applications, that just
want to load and store configuration, do not see any difference in a
well-configured, fine-tuned system.
To support that experience, a so-called default backend
is responsible in
the case that nothing was configured so far. It must have a storage that is
able to store full Elektra semantics including every type and arbitrary
metadata. To avoid reimplementation of storage plugins, for default storage
plugins a resolver plugin additionally takes care of the inevitable
The default backend is guaranteed to stay mounted at system/elektra
the configuration for Elektra itself is stored. After mounting all backends,
Elektra checks if system/elektra
still resides at the default backend.
If not, it will be mounted there.
To summarise, this approach delivers a good out-of-the-box experience capable of
storing configuration. For special use cases, applications and administrators
can mount specific backends anywhere except at, and below,
. On kdbOpen()
, the system bootstraps itself
starting with the default backend.
The default backend consists of a default storage plugin and default resolver
plugin. The default resolver has no specific requirements, but the default
storage plugin must be able to handle full Elektra semantics. The backend is
not mounted anywhere in particular, so any keys can be stored in it. The
implementation of the core guarantees that user and system keys always stay