Elektra is a library implementing access to a global key database. The Global key database provides global access to all key databases of all applications in a system that wants to access a key database. To elektrify an application means to change the application so that it uses Elektra afterwards.

Information on Elektra can be found on the website. For introduction in the terminology, make sure to read the glossary.

Motivation

Why Elektra?

Configurations, settings and preferences are hierarchical data structures of keys, each consisting of a name and a value. They can be used to configure software for the user's needs. Because these settings stay the same across restarts of the program, they need to be stored permanently. In the beginning this was done with primitive text files. Possibilities to structure the text were added later.

Nearly every system developed its own way to read preferences, but some systems can also change them. Because the graphical user interface can be tweaked in many ways, the most encompassing systems emerged from this area. Some got a de facto standard for a desktop environment (kconfig, gconfig) or even an operating system (Windows Registry, Open Directory). But they have a common problem: they are bound to the platform for which they were developed. On the other hand, there are many libraries that do a good job in parsing and writing configuration files. These tools are, however, not powerful enough to keep the configuration independent from the operating system's details, for example, how to resolve the file name of the configuration file.

That is where Elektra comes in to fill the gap. On the one hand, Elektra is not tied to any platform or operating system. On the other hand, Elektra is powerful enough to be useful immediately for what it is written for: to access configuration.

Why is it important?

The configuration files that represent key databases can have binary or humanly-readable formats. From the latter, an unmanageable number is established. Developers of programs tend to document the format of the configuration file extensively. The configuration file may give a special flavour to a specific program and users frequently need it.

Sometimes limitations in the configuration file even lead to rewrites of software. For example, inetd has a non-modular flat configuration file that is not extensible because of a limited number of rows. In order to extend its functionality, the program had to be rewritten with a new approach to configuration: xinetd emerged. Both of these projects are now almost defined by their configuration files giving them identity and separating them from each other. Elektra has introduced backend 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. What makes the difference is the situation that every program can access any configuration because of the abstraction. In the example of inetd, Elektra allows an elektrified inetd respective xinetd to store its configuration in /etc/inetd.conf respective /etc/xinetd.conf. Additionally, each other program interested in these preferences can access them in a uniform way.

To support a global key database, a mutual agreement on some level is needed. Elektra provides this common layer with its data structures. Each elektrified application lies on top of this abstraction layer and it can talk to each part of the global key database using the classes presented next.