The Elektra API
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:
There is also a library that provides some optional XML manipulation methods called KDB Tools, and to use it you should include:
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
Or if you need the options XML manipulation methods, you should use:
bash$ cc `pkg-config --libs elektratools` -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:
KDB
Key
KeySet
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.
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.
Elektra itself cant store configuration to harddisk, this work is delegated to the backends.
- ... of users perspective If you are a
user
of elektra, you will need following information:
- ... of developers perspective 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 , KeySet , KDB . Then you can start reading about Backends :