xenial (7) elektra-contracts.7.gz

NAME

       elektra-contracts - contracts for plugins

       Each  plugin  in  a  backend  can  cause  run  time errors. Additionally, the chaining of the plugins can
       introduce further run time errors. For example, a plugin can modify keys so that the next  plugin  cannot
       process  these  keys  anymore.  Or  a  plugin  can omit changes to the keys that are required by the next
       plugin. To deal with such situations in a controlled way, each plugin exports a contract  that  describes
       the interaction with other parts of the backend. A KeySet contains the description.

       Mounting  of  backends actually takes place at run time, we will refer to it as mount time. The time when
       applications access the key database, however, will be called run time.

       The contract checker revises contracts of plugins during the mount time. Afterwards, at run time, no such
       type  errors  can  occur. kdb mount implements the contract checker. It can refuse to add a plugin to the
       backend because of a conflict or constraint. As long as not all contracts are satisfied kdb  mount  waits
       for more plugins to be attached.

       The content of the contract is well-specified in CONTRACT.ini /doc/CONTRACT.ini.

       Plugins are the only place to export contracts, but they are not the only party. It is also possible that
       the administrator extends the requirements to every backend, for example, if  notification  is  required.
       This  implies  that every backend has to provide a specific additional service that will be checked using
       contracts. Plugins are also involved in contracts with Elektra´s core. This topic will  be  discussed  in
       elektra-algorithm(7) elektra-algorithm.md in which the algorithm used by Elektra´s core is explained.

Assertions

       Contracts  as  introduced by Meyer define preconditions and postconditions on routines. Assertions handle
       these conditions by checking them before entering or after leaving a routine. Because most  of  this  can
       happen only at run time, it often leaves the user alone with an exception.

       Elektra  goes  a step further. Instead of exiting the normal control flow when a precondition is not met,
       it is the responsibility of a special plugin to handle the situation and make sure that the  precondition
       is  met  afterwards.  Sometimes  this  is  not  possible. In these cases, the plugins check the necessary
       conditions and return with error code when they are not met. As we will  see,  these  situations  do  not
       occur very often.

       Because  of  the  modular  approach,  we  can  have  several checkers, and correcting and checking can be
       combined. Plugins can work together to reach a certain goal.

       KeySet and Key already handle most parts of checking pre- and postconditions imposed on data  structures.
       Elektra´s core provides preconditions and weak postconditions for the plugins.

SEE ALSO

       •   elektra-ordering(7) elektra-ordering.md

                                                  November 2015                             ELEKTRA-CONTRACTS(7)