NAME

       doc_decisions_specification_mdTemplate
        -

   Issue
       • The commandline for mounting a backend can be very long

       • A specification is already used for code generation, but

         • the data is not available in KDB

         • the  specification  cannot  be  used  for  mounting,  even  though  the  needed information is in the
           specification

   Constraints
       • the specification must be simple to use

       • there must be a clear mapping between keys and configuration file entries

       • there must be a 1:1 mapping of keys used within an application and the specification

   Assumptions
       • The user will have a variable for each configuration value (e.g. by using a binding) if she cares about
         access performance

       • memory footprint is expected to be low

   Considered Alternatives
       • modifying kdbGet() and ksLookup() so that we get a logical hierarchy

       • having a duplicated in memory hierarchy with the cascaded keysets

   Decision
   Argument
       • 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.

   Implications
       1.  Introduction of spec/ hierarchy

       2.  kdbGet() for cascading

       3.  kdbSet() for cascading

       4.  modify ksLookup() for cascading

       5.  KDB_O_DEFAULT in ksLookup()

       6.  define necessary meta data

       7.  mounting spec files

   Related decisions
   Notes
Version 0.8.14                                   Mon Jul 24 2017        doc_decisions_specification_md(3elektra)