- relation of keys to files
Keys of a backend can only be retrieved as a full key set. Currently it is not
possible to fetch a part of the keys of a backend. So the user needs to cut
out the interesting keys with ksCut()
afterwards. If the keys should be
committed again, the whole key set must be preserved. Otherwise, the clipped
keys will be removed permanently.
This restriction simplifies storage plugins while it does not limit the user.
Other plugins would not be able to fulfil their purpose without the full
. For example, a plugin that checks the availability and
structure of all keys cannot work with a partial key set.
It is problematic to have too many keys in one backend. The applications would
need memory for unnecessary configuration data. Instead we recommend
introducing several mount points to split up the keys into different backends.
Splitting up key sets makes sense if any application requests only a part of
the configuration. No benefits arise if every application requests all keys
Let us assume that many keys reside in user/sw
and an application only
needs the keys in user/sw/app
. To save memory and get better startup
times for the application, a new backend can be mounted at user/sw/app
On the other hand, every mounted backend causes a small run time overhead in
the overall configuration system.
The solution in Elektra is flexible, because the user decides the granularity.
It is possible to mount a backend on every single key, so that every key can
be requested for itself. If no backends are mounted, all keys reside in the
To sum up, Elektra´s core searches for the nearest mount point and gets
the configuration from there. It is possible that the user gets more
configuration than requested. The user can decide by means of mounting how
much configuration on specific requests are returned.