Namespaces and Key Names

From Elektra Initiative

All keys are organized in a hierarchical tree with 2 Namespaces (subtrees) as showed in the picture:

system Tree

Contains all subsystems and global application keys/configuration. Equivalent to files under /etc directory.

user Tree

The current user's keys. Equivalent to the dotfiles in a user's $HOME directory. These keys are phisically stored under the owner user home directory. The many user:username in the picture shows the full name of those trees. Read about user domains bellow for more.

User Domains

Different from the system namespace, the user namespace is dynamic. For example, the key user/env/PATH may have completely different values for users luciana and valeria. In this example, if valeria wants to access this key at luciana's space, it should refer to user:luciana/env/PATH. Access permissions apply.

User domains were implemented also to address situations when different user names ($USER) have same UID. So a user key is stored in his home directory based on the user name, not the UID. Inactive Keys

A great thing about text configuration files is that some configuration items can be there as an example, but inactive or commented. Elektra provides a very simple way to simulate this behavior: if the key name begins with a dot (.), it is considered inactive or commented. In real world applications, the Elektra API will ignore these keys by default, but the keys are still accessible if the developer wants to.

These are some keys that have inactive subtrees:

• system/sw/XFree/InputDevice/.Mouse3/Driver: All keys under .Mouse3/* subtree won't be read by default.
• user:valeria/env/env2/.PATH: The $PATH environment variable won't be set when valeria login.
• system/users/.louis/uid: The entire .louis/* subtree is inactive. This is the same as commenting the user entry from a configuration file.