Elektra is a universal hierarchical configuration store, with related goals like GConf and the Windows Registry. It allows programs to read and save their configurations with a consistent API, and allows them to be aware of other applications' configurations, leveraging easy application integration. The whole point of it is to tie applications together, so that they can co-operate and share their user-preferences.
The developers are associated to unix philosophy and the very practical point consists of writing a configuration library. Every software needs this functionality, it is not easy to do it right and performant and we want to avoid any unnecessary code duplication.
See the website for more information http://www.libelektra.org
Please report all bugs related to interface, documentation or implementation http://bugs.libelektra.org
1. API implementation to access the key/value pairs namespace 2. Implement the API with a variety of Backends and Bindings 3. Definition of a standard key/value pair hierarchy, namespace and semantics
This document occupies with the API implementation, documentation, internals and backends. 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 using this description.
See http://www.libelektra.org/Tutorial for first Introduction.
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
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.
See http://www.libelektra.org/Bindings for Bindings.
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:
user/
or system/
key, etcThere are 2 trees of keys: system
and user
When using Elektra to store your application's configuration and state, please keep in mind the following rules:
system
or user
. They are reserved for more generic purposes.system/sw/MyApp/current
and user/sw/MyApp/current
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.Elektra itself cant store configuration to harddisk, this work is delegated to the backends.