Skip to content
This repository has been archived by the owner on Oct 15, 2024. It is now read-only.

Latest commit

 

History

History
122 lines (89 loc) · 4.2 KB

elektra-glossary.md

File metadata and controls

122 lines (89 loc) · 4.2 KB
Raw

elektra-glossary(7) -- glossary of Elektra

  • 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 '--'.

  • Module: The parts Elektra is composed of, i.e. either lib, plugin, backend, tool.

  • Class: A group of functions that logically belong together, working on the same type of objects. A library may implement several classes. E.g., KDB, Key and KeySet are the most important classes.

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 Value: The absence of a value, i.e. keyValue (key) == NULL.

  • pop: used in ksPop() and @ref KDB_O_POP means to remove a key from a keyset.

  • delete: or abbr. del, used in keyDel(), ksDel() and @ref 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.