elektra-glossary(7) – glossary of Elektra

Introduction

• Configuration settings: customize applications towards the users' needs. It fulfills following properties:
  • It is provided by the execution environment.
  • It can be changed by the maintainer, user, or system administrator of the software.
  • It consists of a key name, a configuration value, and potentially metadata.
• A configuration file: is a file containing configuration settings.
• Configuration storage: makes configuration settings persistent. The application will read the configuration at every start from the configuration storage, but it is only stored if a user changes settings.
• Key databases: are used for configuration storages because of these constraints. They can do fast key lookups and the keys can be structured hierarchically by defining separators in the key names.
• Global key database: provides global access to all configuration storages of all applications in a system. Abbreviated as KDB.
• LibElektra: is a set of libraries to access configuration parameters in a global, hierarchical key database.
• SpecElektra: is a specification language that allows us to describe the content of the global key database.
• Elektra: is a framework consisting of LibElektra, SpecElektra, and a collection of tools.
• To elektrify an application: to change the application so that it uses LibElektra afterwards.
• Elektra Initiative: is a community that develops LibElektra, expands SpecElektra, improves Elektra's tooling and helps to elektrify applications.
• Option, more specifically Command-line option: is a special argument passed on the command-line. Short options are single characters prefixed with '-'; Long options are arbitrarily long and start with '–'.

Technical Concepts

• Backends: A collection of plugins to be mounted. A backend typically is responsible to read and write a configuration file.
• Bootstrapping: To read the mounting configuration and mount during kdbOpen().
• Cascading: To consider multiple places to look for a key.
• Contracts: Contracts state the purpose, functionality and requirements of plugins.
• Mounting: To persistently and permanently include a backend in the global key database. The mountpoint is the key where the backend is mounted to. All keys of the backend are below that key.
• Key name: All keys in the KDB have a name. This name is the keys unique identifier and follows a particular structure. For more information take look at the keyname documentation.
• Key name part: Key names consist of a series parts (and a namespace).
• Key base name: The last part of a key name.
• Key dir name: The key name obtained by omitting both namespace and base name from a key name.
• Namespaces: Allow us to have multiple keys for the same purpose and otherwise the same key name.
• Plugins: The unit of implementation for a feature.
• Metadata: Allows us to describe configuration settings.

Details

• Sync Flag: Marks keys that were changed and need to be written out to disc.
• Null Keys, Null Values: The absence of keys or values.
• pop: used in ksPop() and KDB_O_POP means to remove a key from a keyset.
• delete: or abbr. del, used in keyDel(), ksDel() and KDB_O_DEL means to free a key or keyset. The memory can be used for something else afterwards.
• remove: means that the key-value information in the physical database will be removed permanently.