The Elektra API

Elektra Initiative Overview

Elektra provides a universal and secure framework to store configuration parameters in a global, hierarchical key database. The core is a small library implemented in C. The plugin-based framework fulfills many configuration-related tasks to avoid any unnecessary code duplication across applications while it still allows the core to stay without any external dependency. Elektra abstracts from cross-platform-related issues with an consistent API, and allows applications to be aware of other applications' configurations, leveraging easy application integration.

See the website for more information http://www.libelektra.org

API docu

This document occupies with the API implementation, documentation, internals and plugins. On the one hand it gives an overview and an introduction for developers using Elektra, on the other hand it gives an informal descriptions 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 http://doc.libelektra.org/api/current/html

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

Using the Elektra Library

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

#include <kdb.h>

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

bash$ cc `pkg-config --libs elektra` -o myapp myapp.c

Elektra API

The API was written in pure C because Elektra was designed to be useful even for the most basic system programs, which are all made in C. Also, being C, bindings to other languages can appear easily.

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

• The four lowlevel functions
• Open and Close the Database
• Get and Set KeySet in the Database
• See class documentation for more

Key

• Get and Set key properties like name , string or binary values, permissions , changed time and comment
• Test if it is a user/ or system/ key, etc
• See class documentation for more

KeySet

• Linked list of Key objects
• Append a single key or an entire KeySet
• Work with its internal cursor
• See class documentation for more

Key Names and Namespaces

There are 2 trees of keys: system and user

• The "system" Subtree It is provided to store system-wide configuration keys, that is, configurations that daemons and system services will use. But all other programs will also try to fetch system keys to have a fallback managed by the distributor or admin when the user does not have configuration for its own.

• The "user" Subtree Used to store user-specific configurations, like the personal settings of a user to certain programs. The user subtree will always be favoured if present (except for security concerns the user subtree may not be considered). See Cascading in the documentation of ksLookupByName() how the selection of user and system keys works.

Rules for Key Names

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

• You are not allowed to create keys right under system or user. They are reserved for more generic purposes.
• The keys for your application, called say MyApp, should be created under system/sw/MyApp/current and user/sw/MyApp/current
• current is the default configuration profile, users may symlink to the profile they want.
• That means you just need to kdbGet() system/sw/MyApp/profile and user/sw/MyApp/profile and then ksLookupByName() in /sw/MyApp/profile while profile defaults to current, but may be changed by the user or admin. See Cascading to learn more about that feature.

Backend Overview

The core of elektra does not store configuration itself to the harddisk. 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, which are composed out of Plugins.

Glossary

• pop, used in ksPop() and KDB_O_POP means to remove a key from a keyset.
• delete, or abbr. del, used in keyDel(), ksDel() and KDB_O_DEL means to free a key or keyset. The memory can be used for something else afterwards.
• remove means that the key/value information in the physical database will be removed permanently.