.TH "doc_decisions_capabilities_md" 3elektra "Sun May 29 2016" "Version 0.8.14" "Elektra" \" -*- nroff -*-
.ad l
.nh
.SH NAME
doc_decisions_capabilities_md \- Capabilities 

.SS "Issue"
.PP
Every backend, except \fCfilesys\fP, was unable to represent full file system semantics\&. Capabilities described the differences between \fCfilesys\fP and another backend\&. (For POSIX file systems a similar technique is \fCpathconf()\fP\&. 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 \fCfilesys\fP works and let the backend still have predictable behaviour\&. The user could query a backend if it was capable of a specific detail of file system semantics\&.
.PP
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\&.
.PP
Getting a single key works well for \fCfilesys\fP\&. 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\&.
.PP
But we soon found the limits of capabilities\&. Capabilities were unable to describe:
.PP
.IP "\(bu" 2
that some key names are not allowed\&.
.IP "\(bu" 2
that not every structure of configuration is allowed\&.
.IP "\(bu" 2
that some characters are not allowed\&.
.IP "\(bu" 2
that only specific key values are allowed\&.
.PP
.PP
.SS "Constraints"
.PP
.SS "Assumptions"
.PP
.SS "Considered Alternatives"
.PP
.SS "Decision"
.PP
No capabilities are used, but instead other plugins implement the limitations other plugins have\&.
.PP
.SS "Argument"
.PP
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\&.
.PP
.SS "Implications"
.PP
.SS "Related decisions"
.PP
.SS "Notes"