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

.SS "Issue"
.PP
.IP "\(bu" 2
The commandline for mounting a backend can be very long
.IP "\(bu" 2
A specification is already used for code generation, but
.IP "  \(bu" 4
the data is not available in KDB
.IP "  \(bu" 4
the specification cannot be used for mounting, even though the needed information is in the specification
.PP

.PP
.PP
.SS "Constraints"
.PP
.IP "\(bu" 2
the specification must be simple to use
.IP "\(bu" 2
there must be a clear mapping between keys and configuration file entries
.IP "\(bu" 2
there must be a 1:1 mapping of keys used within an application and the specification
.PP
.PP
.SS "Assumptions"
.PP
.IP "\(bu" 2
The user will have a variable for each configuration value (e\&.g\&. by using a binding) if she cares about access performance
.IP "\(bu" 2
memory footprint is expected to be low
.PP
.PP
.SS "Considered Alternatives"
.PP
.IP "\(bu" 2
modifying \fBkdbGet()\fP and \fBksLookup()\fP so that we get a logical hierarchy
.IP "\(bu" 2
having a duplicated in memory hierarchy with the cascaded keysets
.PP
.PP
.SS "Decision"
.PP
.SS "Argument"
.PP
.IP "\(bu" 2
The user wants deterministic retrieval of configuration\&. It must be answerable (w/o study of sourcecode and debugging) which value will be used in the current situation\&.
.PP
.PP
.SS "Implications"
.PP
.IP "1." 4
Introduction of spec/ hierarchy
.IP "2." 4
\fBkdbGet()\fP for cascading
.IP "3." 4
\fBkdbSet()\fP for cascading
.IP "4." 4
modify \fBksLookup()\fP for cascading
.IP "5." 4
KDB_O_DEFAULT in \fBksLookup()\fP
.IP "6." 4
define necessary meta data
.IP "7." 4
mounting spec files
.PP
.PP
.SS "Related decisions"
.PP
.SS "Notes"