Elektra  0.9.3
Elektra Initiative Overview

Elektra serves as a universal and secure framework to access configuration parameters in a global, hierarchical key database and provides a mature, consistent and easily comprehensible API. Its modularity effectively avoids code duplication across applications and tools regarding configuration tasks. Elektra abstracts from cross-platform-related issues and allows applications to be aware of other applications' configurations, leveraging easy application integration.

See the readme for more introduction. See the glossary for the used terminology.

This document's main goal is to describe the API. It covers:

On the one hand it gives an overview and an introduction for developers using Elektra, on the other hand it gives an informal description what methods must and may provide to allow an alternative implementation of the API.

The current version (for stable releases) of this document can be found at https://doc.libelektra.org/api/current/html

The latest version (from git master) of this document can be found at https://doc.libelektra.org/api/latest/html

Important: On GitHub links to API functions are broken, so it is recommended that you continue reading in one of these links above.

A C or C++ source file that wants to use Elektra should include:

#include <kdb.h>

To link an executable with the Elektra library, one way is to use the pkg-config tool:

gcc -o application `pkg-config --cflags --libs elektra` application.c

Another way is to use CMake:

find_package(Elektra REQUIRED)
include_directories (${ELEKTRA_INCLUDE_DIR})
target_link_libraries (application ${ELEKTRA_LIBRARIES})

Read about compiling elektra.

List of all available Plugins and get started by developing your own plugins Plugins.

The API was written in pure C because Elektra was designed to be useful even for the most basic system programs.

The API follows an object-oriented design, and there are 3 main classes as shown by the figure:

Elektra Classes

Some general things you can do with each class are:

KDB (Key Database)



More background information about the classes

There are 5 trees (=namespaces) of keys: spec, proc, dir, user and system that are all unified (in the given order) in one cascading tree starting with /.

The cascading tree is the logical tree to be used in applications. The other trees are the physical ones that stem from configuration sources. When using cascading key the best key will be searched at run-time, which appears like a tree on its own. See cascading in the documentation of ksLookupByName() on how the selection of keys works.

Read more about namespaces and a tutorial for namespaces.

When using Elektra to store your application's configuration and state, please keep in mind the following rules:

Read more about key names

The core of Elektra does not store configuration itself to the hard disk. Instead this work is delegated to backends.

If you want to develop a backend, you should already have some experience with Elektra from the user point of view. You should be familiar with the data structures: Key and KeySet Then you can start reading about Backends that are composed out of Plugins. To get started with writing plugins, first read our plugin tutorial and then lookup details in the API description in Plugins.

Read more about mounting