Elektra
0.8.16
|
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
Some nice features that will be implemented as global plugins.
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)
simplifies threading and process locking by not having to think about recursive cases.
Run shell code at end of all plugins, e.g. especially doing
git add git commit
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
It should be possible to write plugins which need all file names of all resolver plugins. E.g. journalling, global mmap.
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.
Plugin *globalPlugins [NR_OF_PLUGINS]
to _KDB
kdbOpen
, system/elektra/globalplugins/
is read and plugins are constructed and placed into globalPlugins
.list
plugins, and their subplugins are executed, when system/elektra/globalplugins/_
states they should be executedlock
plugin that executes at begin and end of kdbGet and kdbSet, respective, i.e. postrollback preget postget preset postcommitlock
plugin contains the code currently found in resolver