Provided by: elektra-doc_0.8.14-5.1ubuntu2_all bug

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