NAME

       elektra-backends - 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 these
       details.

       Since Elektra 0.8 a backend is composed of many plugins.

MULTIPLE 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 Elektra.

       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
       plugins. 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 existing plugins.

SEE ALSO

       •   More information about elektra-plugins(7) elektra-plugins.md

       •   The tool for mounting a backend is kdb-mount(1) kdb-mount.md

       •   The plugins are ordered as described in elektra-plugins-ordering(7) elektra-plugins-ordering.md

                                                    July 2017                                ELEKTRA-BACKENDS(7)