Every key in Elektra has a unique name. Sometimes, multiple keys denote the same configuration item from different sources, e.\+g.\+:


\begin{DoxyItemize}
\item by a commandline argument
\item by a configuration file found below the home directory
\item by a configuration file found below /etc
\end{DoxyItemize}

To allow such keys to exist in parallel, Elektra uses namespaces.

A namespace has following properties\+:


\begin{DoxyItemize}
\item in-\/memory Keys can start with this name
\item these keys stem from a specific configuration source
\item \hyperlink{group__keyset_gaa34fc43a081e6b01e4120daa6c112004}{ks\+Lookup()} uses namespaces in a specific default order unless specified otherwise
\end{DoxyItemize}

Following parts of Elektra are affected by namespaces\+:


\begin{DoxyItemize}
\item the key name validation in \hyperlink{group__keyname_ga7699091610e7f3f43d2949514a4b35d9}{key\+Set\+Name()}
\item \hyperlink{group__keyname_gafc3ca03ed10f87eb59bdc02cf2a0de8d}{key\+Get\+Namespace()} which enumerates all namespaces
\item \+\_\+\+Backend and \hyperlink{split_8c}{split.\+c} for correct distribution to plugins (note that not all namespaces actually are distributed to configuration files)
\item \hyperlink{mount_8c}{mount.\+c} for cascading and root backends
\item and of course many unit tests
\end{DoxyItemize}

In the rest of this document all currently available namespaces in the default order are described.

\subsection*{spec}

Unlike the other namespaces, the specification namespace does not contain values of the keys, but instead meta data as described in \href{/home/markus/Projekte/Elektra/current/doc/METADATA.ini}{\tt M\+E\+T\+A\+D\+A\+T\+A.\+ini}.

When a key is looked up, keys from the spec-\/namespace are the first to be searched. When a spec-\/key is found, the rest of the lookup will be done as specified, probably in a different order than the namespaces enlisted here.

Usually, the spec-\/keys do not directly contribute to the value, with one notable exception\+: the default value (meta data {\ttfamily default}, see in cascading below) might be used if every other way as specified in the spec-\/key failed.

Spec-\/keys typically include a explanation and description for the key itself (but not comments which are specific for individual keys).

The spec configuration files are below C\+M\+A\+K\+E\+\_\+\+I\+N\+S\+T\+A\+L\+L\+\_\+\+P\+R\+E\+F\+I\+X/\+K\+D\+B\+\_\+\+D\+B\+\_\+\+S\+P\+E\+C.

spec is not part of cascading mounts, because the specifications often are written in different syntax than the configuration files.

\subsection*{proc}

Derived from the process (e.\+g. by parsing /proc/self or by arguments passed from the main method)\+:


\begin{DoxyItemize}
\item program name
\item arguments
\item environment
\end{DoxyItemize}

Keys in the namespace proc can not be stored by their nature. They might be different for every invocation of an application.

\subsection*{dir}

Keys from the namespace {\ttfamily dir} are derived from a directory special to the user starting/using the application, e.\+g.\+:


\begin{DoxyItemize}
\item the current working directory for project specific settings, e.\+g. .git
\item the directory a server wants to present to the user, e.\+g. .htaccess
\end{DoxyItemize}

Note that Elektra only supports a single special directory per K\+D\+B instance. Start a new K\+D\+B instance if you need different special directories for different parts of your application. How to change the directory may be different dependent on the resolver, e.\+g. by using chdir or by setting the environment variable P\+W\+D

\subsection*{user}

On multi-\/user operating systems obviously every user wants her/his own configuration. The user configuration is located in the users home directory typically below the folder K\+D\+B\+\_\+\+D\+B\+\_\+\+U\+S\+E\+R. Other paths below the home directory are possible too (absolute path for resolver).

Note that Elektra only supports a user directory per K\+D\+B instance. Start a new K\+D\+B instance if you need different user configuration for different parts of your application. How to change the user may be different dependent on the resolver, e.\+g. by seteuid() or by environment variables like H\+O\+M\+E, U\+S\+E\+R

\subsection*{system}

The system configuration is the same for every chroot.

The configuration is typically located below K\+D\+B\+\_\+\+D\+B\+\_\+\+S\+Y\+S\+T\+E\+M. Other absolute paths, e.\+g. below /opt or /usr/local/etc are possible too.

\subsection*{cascading}

Keys that are not in a namespace (i.\+e. start with an {\ttfamily /}) are called cascading keys. Cascading keys do not stem from a configuration source, but are used by applications to lookup a key in different namespaces. So, multiple keys can contribute to each cascading key name.

Cascading is the same as a name resolution and provides a namespace unification as described in \href{http://dl.acm.org/citation.cfm?id=1138045}{\tt Versatility and Unix semantics in namespace unification}.

Keys without a namespace can not be stored by their nature. So they are transient\+: after a restart they are forgotten.

Keys of that namespace are only used by ks\+Lookup when no other suitable key was found. So they have the lowest possible priority, even fallback keys are preferred.

\hyperlink{md_doc_help_elektra-cascading_doc_help_elektra-cascading_md}{Read more about cascading.} 