$darkmode
Elektra 0.11.0
|
The goal of Elektra is to make it trivial to access and specify configuration settings by an API. This helps in achieving the following goals:
Elektra follows the goals below, in order of preference. If goals conflict, the higher goal takes precedence.
People need to be able to rely on the API/ABI to be stable. They expect their configuration settings to continue working, with minimal maintenance burden. In particular following parts must be immutable:
x.0.0
must still compile with any x.y.z
. Even with new major releases, only small adoptions in the source of applications or plugins might be needed.x.0.0
will continue to link with any future version of Elektra. We use symbol versioning for that goal.Elektra is based on key-value pairs, the simplest form of what could be called a database. Elektra's key value pair uniformity allows with a single concept configuration settings and configuration specifications to be written and to be introspected.
An overly complex system cannot be managed nor understood. Extensibility brings some complex issues, which need to be solved – but in a way so that the user sees either nothing of it or only needs to understand very simple concepts. Special care for simplicity is taken for the users:
Configuration systems today suffer badly from:
We tackle this problem by introducing an abstraction layer where these problems are dealt with. The goal is that for improvements in these areas only code changes within Elektra are needed (and not within applications using Elektra). This makes the application's code not only portable towards more systems, but also enables global improvements in configuration systems.
There are many variants of
Nearly every aspect of Elektra must be extremely extensible. On the other side semantics must be very clear and well-defined so that this extensible system works reproducible and predictable.
Only key-value pairs are the common factor and a way to get and set them, everything else is an extension.
Accessing configuration settings has impact on bootup and startup-time of applications. Elektra needs to have similar performance as current solutions. Of particular importance is that kdbGet
invocations:
The plugin system has as guideline:
Only pay for what you need.
These goals are about Elektra's users, again in order of importance. Again, lower goals need to be ignored if goals are in conflict.
Elektra must be easy and robust for application developers to store any configuration settings referable by keys they need to store. After writing configuration settings (kdbSet
) and reading them again (kdbGet
) they get the same KeySet (aka "round-trip").
This means, they must be able to store keys with any name, any string or any binary data as needed for their purpose.
Administrators should be empowered by good error messages and validation capabilities. Furthermore, they should be able to use their favorite tools and configuration file formats.
There are principal limitations of nearly all configuration file formats, so Elektra cannot enable that any configuration file format can be used with any application. If maintainers or administrators want to change the configuration file format of some application, they need to carefully test if it works.
Elektra must be available everywhere and flexible enough, so that maintainers can integrate different applications by specifying and mounting.
There might be some restrictions that some applications require some plugins to be mounted for their configuration settings.
Elektra must be powerful and flexible enough to be able to represent any configuration file format. We support the development of fully-conforming parsers and emitters.
This means, that given a correctly written storage plugin, a KeySet can be found that represents the configuration settings, its metadata and the hierarchical structure of the configuration file.
kdbGet()
/kdbSet()
interface.