\hypertarget{doc_decisions_capabilities_md_autotoc_md1058}{}\doxysection{Problem}\label{doc_decisions_capabilities_md_autotoc_md1058}
Every backend, except {\ttfamily filesys}, was unable to represent full file system semantics. Capabilities described the differences between {\ttfamily filesys} and another backend. (For P\+O\+S\+IX file systems a similar technique is {\ttfamily pathconf()}. It allows the user to query the capabilities of a specific mounted file system given by path.) Capabilities made it possible to implement a backend different from the way {\ttfamily filesys} works and let the backend still have predictable behavior. The user could query a backend if it was capable of a specific detail of file system semantics.

Capabilities were initially introduced to make backend development easier, because they also expressed the disabilities of a backend. For example, it was possible for a backend to claim that it is not aware of comments.

Getting a single key works well for {\ttfamily filesys}. However, for configuration files the whole content must be parsed even for a single key. Capabilities were able to describe that the backend will always retrieve and store all keys and will not be able to retrieve and store individual keys. This restriction simplified the implementation of such backends considerably. Capabilities allowed us to implement fstab, passwd and hosts backends.

But we soon found the limits of capabilities. Capabilities were unable to describe\+:


\begin{DoxyItemize}
\item that some key names are not allowed.
\item that not every structure of configuration is allowed.
\item that some characters are not allowed.
\item that only specific key values are allowed.
\end{DoxyItemize}\hypertarget{doc_decisions_capabilities_md_autotoc_md1059}{}\doxysection{Constraints}\label{doc_decisions_capabilities_md_autotoc_md1059}
\hypertarget{doc_decisions_capabilities_md_autotoc_md1060}{}\doxysection{Assumptions}\label{doc_decisions_capabilities_md_autotoc_md1060}
\hypertarget{doc_decisions_capabilities_md_autotoc_md1061}{}\doxysection{Considered Alternatives}\label{doc_decisions_capabilities_md_autotoc_md1061}
\hypertarget{doc_decisions_capabilities_md_autotoc_md1062}{}\doxysection{Decision}\label{doc_decisions_capabilities_md_autotoc_md1062}
No capabilities are used, but instead other plugins implement the limitations other plugins have.\hypertarget{doc_decisions_capabilities_md_autotoc_md1063}{}\doxysection{Rationale}\label{doc_decisions_capabilities_md_autotoc_md1063}
The main problem was that the complexity was just moved to the applications. In the end, application developers had to understand what the backend can write out. They no longer had confidence that the storage was able to understand the full semantics. Elektra’s core was unable to hide that fact. Capabilities did not turn out to make backend development much easier. Instead, Elektra was more difficult to use with capabilities. Capabilities are no longer part of Elektra for these reasons.\hypertarget{doc_decisions_capabilities_md_autotoc_md1064}{}\doxysection{Implications}\label{doc_decisions_capabilities_md_autotoc_md1064}
\hypertarget{doc_decisions_capabilities_md_autotoc_md1065}{}\doxysection{Related Decisions}\label{doc_decisions_capabilities_md_autotoc_md1065}
\hypertarget{doc_decisions_capabilities_md_autotoc_md1066}{}\doxysection{Notes}\label{doc_decisions_capabilities_md_autotoc_md1066}
