- the backend concept
Elektra has introduced *backends** to support the storage of key databases in
different formats. Elektra abstracts configuration so that applications can
receive and store settings without carrying information about how and where
these are actually stored. It is the purpose of the backends to implement
Since Elektra 0.8 a backend is composed of many plugins.
Its clear that too many features in one backend is problematic. It introduces
unwanted external dependences and leads to less portable backends. Many
different aspects clutter the code making the backends unmaintainable.
Features of other backends cannot be taken with ease because they are
interwoven with other code.
To support the reuse of a functionality, they must be useful in different
situations. Separation of concerns is required for that. Each backend needs to
have a specific purpose rather than implementing the full semantics of
It was impossible to implement powerful and feature-rich backends so far because
of the lack of modularity. Desirable features like notification and type
checking have always been in the developers´ heads, but there was no
place where it would fit in without making the system unmaintainable, complex
and full of unwanted external dependences.
To solve this dilemma, Elektra uses multiple plugins
together build up a
backend. The key set processed by one plugin will be passed to the next. This
approach allows us to implement separate features in separate plugins. Plugins
concerned with reading and writing to permanent storage are called storage
. We cleaned existing backends from other tasks so that their only
job now is related to the storage. Using this approach, the plugins provide
the desired separation of concerns inside a backend.
Each plugin implements a single concrete requirement and it does that well. This
architecture allows plugins to have external dependence. Not every plugin has
the burden to be portable anymore. That is no problem because the plugins are
separate subprojects and maintainers can decide if they should be built for a
specific platform or not. Afterwards users can choose which plugins they want
to install and use. And finally, the administrator can choose which of the
plugins should be loaded for each backend. If a specific feature is not
needed, it is not included and does not cause additional overhead. Given the
chosen approach, the core of Elektra can stay minimal. Most functionality can
be moved to plugins.
Now let us look at the development time
with multiple plugins. The
programmer will find many reusable plugins. Some of them already fulfil given
requirements. While checking the code quality of the plugins, the programmer
actually learns how the plugin works. Given that point of view, the programmer
will decide to use Elektra because he or she can choose from a pool of
- More information about elektra-plugins(7)
- The tool for mounting a backend is kdb-mount(1)
- The plugins are ordered as described in