Elektra  0.8.17
Global Plugins

Issue

Constraints

Assumptions

Considered Alternatives

Decision

Positions

Configuration will be in arrays below the keys:

system/elektra/globalplugins
                             /prerollback
                             /rollback
                             /postrollback
                             /getresolver
                             /pregetstorage
                             /getstorage
                             /postgetstorage
                             /setresolver
                             /presetstorage
                             /setstorage
                             /precommit
                             /commit
                             /postcommit

Additionally, below every of these position following subpositions exist:

                                        /before/init
                                        /after/deinit
                                        /before/once
                                        /after/once
                                        /before/foreach
                                        /after/foreach

With different semantics each:

If not given, per default once and after will be used.

Return values

If a global plugin returns:

Detection within plugins

So that plugins know in which position they currently are, the name of the position will be written as string in parentkey (not starting with slash to distinguish with file names).

Exception: foreach plugins only get filenames, so to know in which foreach loop you are, you need to add additional once placements to correctly track your state.

Contract

Next to positioning information plugins have to state in their 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/status global

Application-Specific global plugins

If you need a global plugin for your application kdbAddGlobalPlugin from libtools can be used. If the global plugin is already present, it should be a NOP. For this functionality #684 is needed.

Use cases:

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.

Now called semlock-plugin.

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

Now called spec-plugin.

Journalling plugins

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

For mmap it could work the following way:

    getresolver/after/foreach

is responsible to check if all files resolved are still the same file (and same number of files), and if the mtime of the mmap file is newer than the resolved file. Iff this is the case for every mountpoint we will (try) to load the mmaped file in:

    getresolver/after/once

The loading of the mmap might fail:

If the loading failed, we will continue by returning 1, if the loading was successful we prematurely abort kdbGet by returning 0.

If we continued with kdbGet we want to persist the KeySet for the next kdbGet() with the same parameters using the global hook:

    getresolver/after/once

Implications

Default global plugins

Its useful to have some important global plugins, e.g. locking by default. See #690.

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