.TH "doc_GOALS_md" 3elektra "Sun May 29 2016" "Version 0.8.14" "Elektra" \" -*- nroff -*-
.ad l
.nh
.SH NAME
doc_GOALS_md \- Goals 

.IP "\(bu" 2
improve robustness of configuration systems
.IP "  \(bu" 4
reject invalid configuration
.IP "  \(bu" 4
avoid common programming errors by using better bindings
.PP

.IP "\(bu" 2
allow software to be better integrated on configuration level
.IP "\(bu" 2
postpone some decisions from programmers to maintainers/administrators:
.IP "  \(bu" 4
syntax of the configuration files
.IP "  \(bu" 4
side effects (e\&.g\&. logging, vcs commit, notifications)
.IP "  \(bu" 4
flexible adoption to specific needs
.IP "  \(bu" 4
adoption of standards (xdg, xml, json)
.PP

.IP "\(bu" 2
reduce duplication of code (a single parser/generator used by everyone accessing a specific part of configuration)
.PP
.PP
.SS "Target"
.PP
.IP "\(bu" 2
Embedded: Elektra is on the frontier for embedded systems because of its tiny core and the many possibilities with it`s plugins\&.
.IP "\(bu" 2
Server: Elektra is ideal suited for a local configuration storage by mounting existing configuration files into the global tree\&. Nodes using Elektra can be connected by already existing configuration management tools\&.
.IP "\(bu" 2
Desktop: Elektra allows applications to read and write from a global configuration tree\&. Missing is a description (schema) so that these values actually can be shared\&.
.PP
.PP
.SS "Quality Goals"
.PP
1\&.) Simplicity
.PP
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 so that it works flawlessly\&. Special care for simplicity is taken for the users:
.PP
.IP "\(bu" 2
Endusers when reconfiguring or upgrading should never take any notice of Elektra, except that it works more robust, better integrated and with less problems\&.
.IP "\(bu" 2
Programmers should have multiple ways to take advantage of Elektra so that it flawlessly integrate with their system\&.
.IP "\(bu" 2
Plugin Programmers: it should be simple to extend Elektra in any desired way\&.
.IP "\(bu" 2
Application`s Maintainers to correctly setup+upgrade KDB
.IP "\(bu" 2
Administrators that want to change the maintainers setup according to their needs
.PP
.PP
2\&.) Robustness
.PP
Configuration Systems today suffer badly from:
.PP
.IP "\(bu" 2
weak input validation
.IP "\(bu" 2
faulty transformations from strings to other types
.IP "\(bu" 2
no error messages
.IP "\(bu" 2
undefined behaviour
.PP
.PP
We want to tackle this problem\&.
.PP
3\&.) Extensibility
.PP
There are so many variants of
.PP
.IP "\(bu" 2
storage formats
.IP "\(bu" 2
frontend integrations
.IP "\(bu" 2
bindings
.PP
.PP
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\&.
.PP
Only key/value pairs are the common factor and a way to get and set them, everything else is an extension\&.
.PP
4\&.) Performance
.PP
Configuration is the main impact for bootup and startup time\&. Elektra needs to be similar fast then current solutions\&. Ideally it should get faster because of centralized optimization endeavours where everyone using Elektra can benefit from\&.
.PP
Only pay for what you need\&.