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



       · 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

       · 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

       · 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

       · 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.

       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