Elektra  0.8.14
Global Plugins

Issue

Constraints

Assumptions

Considered Alternatives

Decision

Configuration will be in arrays below the keys:

system/elektra/globalplugins/
    prerollback
    postrollback
    preget
    postget
    preset
    setstorage
    precommit
    postcommit

Plugins state in contract that they will work as global plugin, i.e. do not need to work on individual config files, when following contract is present:

infos/global

The kdb-tool should have following list-like interface:

kdb global-plugin-add
kdb global-plugin-del
kdb global-plugin-list

Argument

Some nice features that will be implemented as global plugins.

Transformation

Transformation keys which are read and transformed to be usable by the application:

[dir/a]
transform=/x
transform/python=...upper()
         /lua=..

(actually two plugins are involved: one that fetches transformation keys, the other that executes the transformation code)

Global lock

simplifies threading and process locking by not having to think about recursive cases.

Shell plugins

Run shell code at end of all plugins, e.g. especially doing

git add
git commit

Inference plugins

The globbing would be more natural (derived from specification). Or even more advanced ways to copy information from specification to the keys, e.g. type inference

Journalling plugins

It should be possible to write plugins which need all file names of all resolver plugins. E.g. journalling, global mmap.

Implications

Default global plugins

Its useful to have some important global plugins, e.g. locking by default. Internal list to be used when no system/elektra/global_mountpoints/ exists.

State diagrams of plugins need to be redrawn to also include global plugin states.

Related decisions

Notes

Open Points

Implementation Hints