Backends
From Elektra Initiative
Contents |
Introduction
A very important part of libelektra are the kdb* functions. They are provided through backends. They take care that the key and keysets are read and written to the database.
In the unstable Version there will be also the possibility to have multiple backends at once. So you can choose for every application or even every key which backend fits best.
There could be an implementation for every purpose. Berkleydb or fast in-ram hashes for embedded up to sql server requests for thousends of clients. Its up to you: The backends will immediately work with elektrified software.
Filesys
Status: Well maintained by core, full featured, well tested
Filesys stores every key in its own file. Folders are real folders inside the filesystem.
Hosts
Status: Actively maintained, fully working.
/etc/hosts is a simple whitespace separated configuration file with the format
ip-adress canonical-name alias00 alias01 alias02
which will be transformed to keys with the canonical-name and the containing the ip-adress as value. If it is a directory key it has aliases, stored as subkeys alias00 to alias99 and the alias as value.
There is a limitation that it does not read more then BUFFER_SIZE per line, but it is written in pure ansi-c with very short code. Because of that (BUFFER_SIZE is about 256 bytes) you won't reach the 99 aliases :-)
BerkleyDB
Status: Compiles, but does not link statically (Port 0.7)
The whole System-Database is stored into a single file. Every User has also its own Database in his Homedirectory.
Fstab
Status: works well in unstable, Maintained by Markus Raab
set and get in unstable
It uses a file like /etc/fstab to write and read information about filesystems.
Passwd
Status: only reading, Maintained by Patrick Sabin
It uses a file like /etc/passwd to write and read information about users.
Ini
Status: Maintained by Markus Raab, compiles, only reading
Defined in: rfc822 Not fully featured, see source in svn for progress.
This is a ini-style backend. Key/Value Pairs are stored in files in following scheme:
key1=value1;comment
Gconf
Status: outdated, not working, no port to 0.7
Gconf Pairs are stored in Gconf
Daemon
Status: Port to 0.7 missing
Daemon is under sbin/kdbd. Backend is called daemon. It uses DDEFAULT backend.
Libraries
A great feature of elektra is that it could be used as multiplexer for libraries parsing and writing configuration.
Eet
Status: Planning
Eet is extremely fast, small and simple. Eet files can be very small and highly compressed, making them very optimal for just sending across the internet without having to archive, compress or decompress and install them. They allow for lightning-fast random-acess reads once created, making them perfect for storing data that is written once (or rarely) and read many times, but the program does not want to have to read it all in at once.
libconfig
Status: Planning
This file format is more compact and more readable than XML. And unlike XML, it is type-aware, so it is not necessary to do string parsing in application code.
Uniconf
Status: Backend on Uniconf page available, no port to 0.7
Uniconf tries to unify the configuration in a backend level. Application can also access the Uniconf backend with other APIs then Elektra. This is not supported or wished by our project.
If you need another API, write bindings for elektra.
Augeas
Status: Idea
It parses configuration files in their native formats and transforms them into a tree. Configuration changes are made by manipulating this tree and saving it back into native config files.
Winregistry
Status: Some basic code existing, no port to 0.7
This backend tries to transform the content of the W32 Registry Database into elektra namespace.
Configlib
Status: Idea Link: Configlib Licence: BSD License (revised)
ConfigLib is a C++ library designed to read/write configuration files. The three main goals of the project are
- To allow reading and writing of a configuration file with minimal disruption of the data and any comments.
- To ensure that developers adopt an all or nothing stance: adding a variable allows it to do everything needed right away, discouraging a half completed addition that is never actually finished.
- To make adding a new configuration setting as simple as declaring a variable, even if it is a complex object.
RudeConfig
Status: Idea Link: RudeConfig Licence: GPL
The C++ Config File library is used for reading and writing configuration / .ini files.
libINI
Status: Idea Link: libINI Licence: GPL
postfix
Status: Idea Link: Postfix Configuration Licence: GPL
Use Postfix configuration system
Planned
Python
Status: Planning by Markus Raab, Diego Jacobi and Patrick Sabin
XML
Status: Planning by Markus Raab
Use libelektratools serialization technique for a backend.
Network
Status: Draft available
This is just a draft for a proposal for a backend to support ACLs on non-filesystem backends.
apache
Status: Idea, no code available.
Having a backend which can read and write the apache configuration. This would allow to integrate an unpatched apache into elektra.
nvram
Status: Idea, no code available.
Used for embedded system nvram could be very useful as a backend.
Binary
Status: Idea, no code available.
Serialize everything and put it in a file. To get the keyset, just mmap the file and unserialize it. This would be the fastest possible way to get configuration (without daemon).
Curl
Status: Idea, no code available.
Fetching any url supported by libcurl and parsing the configuration out of there (with e.g. Ini).
Images
Status: Idea, no code available.
Using .tar.gz or cramfs to have a fully compressed very small image containing the whole configuration.
