\subsection*{Problem}

Projects usually do not want to use low-\/level A\+P\+Is. {\ttfamily K\+DB} and {\ttfamily Key\+Set} is useful for plugins and to implement A\+P\+Is but not to be directly used in applications.

\subsection*{Constraints}


\begin{DoxyEnumerate}
\item should be extremely easy to get started with
\item should be very hard to use it wrong
\item all high-\/level A\+P\+Is should work together very nicely
\begin{DoxyItemize}
\item same principles
\item same A\+PI style
\item same error handling
\item can be arbitrarily intermixed
\end{DoxyItemize}
\end{DoxyEnumerate}

\subsection*{Assumptions}


\begin{DoxyItemize}
\item Thread-\/safety\+: a handle is the accepted better solution than having to care about whether it is reentrant, thread-\/safe, ...
\item assumes that spec is available (either by compiled-\/in {\ttfamily Key\+Set} or exit after elektra\+Open)
\item many projects do not care about some limitations (no binary, no metadata) but prefer a straightforward way to get/set config
\item When people hit limitations they fall back to direct use of $^\wedge$\+Key\+Set$^\wedge$, $^\wedge$\+Key$^\wedge$
\end{DoxyItemize}

\subsection*{Considered Alternatives}


\begin{DoxyItemize}
\item storing errors in the handle\+:
\begin{DoxyItemize}
\item Maintenance problem if error handling is added later
\end{DoxyItemize}
\item only provide {\ttfamily K\+DB}, applications need to implement their own A\+P\+Is\+:
\begin{DoxyItemize}
\item reduces consistency of how the A\+PI is used
\end{DoxyItemize}
\item only provide generated A\+PI
\item assume type as {\ttfamily string} if not given
\item force {\ttfamily default} to be part of parameters
\end{DoxyItemize}

\subsection*{Decision}

We provide 3 high-\/level C A\+P\+Is\+:


\begin{DoxyEnumerate}
\item libelektra-\/highlevel (generic key-\/value getter/setter)
\item libelektra-\/hierarchy (generic hierarchical getter/setter in a tree)
\item code generator (specified key-\/value getter/setter with function names, Key\+Sets, or strings from specifications)
\end{DoxyEnumerate}

Furthermore, we will\+:


\begin{DoxyItemize}
\item have as goal that no errors in specified keys with default can occur
\item if you use {\ttfamily elektra\+Get\+Type} before getting a value, no error can occur when getting it later
\item enforce that every key has a type
\item use {\ttfamily elektra\+Error} as extra parameter (for prototyping and examples you can pass 0)
\end{DoxyItemize}

\subsection*{Rationale}


\begin{DoxyEnumerate}
\item Very easy to get started with, to get a key needs 3 lines of codes (without error handling)\+:
\end{DoxyEnumerate}


\begin{DoxyCode}
Elektra *handle = elektraOpen (\textcolor{stringliteral}{"/sw/elektra/kdb/#0/current"}, 0);
printf (\textcolor{stringliteral}{"number /mykey is "} ELEKTRA\_LONG\_F \textcolor{stringliteral}{"\(\backslash\)n"}, \hyperlink{group__highlevel_gad4198ec223f01c3a6cfb1b78de34bc9e}{elektraGetLong} (handle, \textcolor{stringliteral}{"/mykey"}));
\hyperlink{group__highlevel_ga9b688b7250e5f9d8ea6701cc2cc269af}{elektraClose} (handle);
\end{DoxyCode}



\begin{DoxyEnumerate}
\item It is also easier to get started with writing new bindings.
\item User can combine the different A\+P\+Is.
\end{DoxyEnumerate}

\subsection*{Implications}

\subsection*{Related decisions}

\subsection*{Notes}

\href{https://issues.libelektra.org/1359}{\tt https\+://issues.\+libelektra.\+org/1359} 