Global Plugins: Use fences for code blocks
Configuration will be in arrays below the keys:
+```
system/elektra/globalplugins
/prerollback
/rollback
@@ -51,13 +52,16 @@ Configuration will be in arrays below the keys:
/precommit
/commit
/postcommit
+```
Additionally, below every of these position following subpositions
exist:
+```
/init
/deinit
/foreach
+```
With different semantics each:
@@ -94,7 +98,9 @@ plugins have to state in their contract that they will work as global plugin, i.
do not need to work on individual config files, when following contract
is present:
+```
infos/status global
+```
### Application-Specific global plugins
@@ -115,10 +121,12 @@ Some nice features that will be implemented as global plugins.
Transformation keys which are read and transformed to be usable by the application:
+```ini
[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)
@@ -137,8 +145,10 @@ Now called `semlock`-plugin.
Run shell code at end of all plugins, e.g. especially doing
+```sh
git add
git commit
+```
### Inference plugins
@@ -154,13 +164,17 @@ 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 mount point we will (try) to load the mmaped file in:
+```
getresolver/after/once
+```
The loading of the mmap might fail:
@@ -174,7 +188,9 @@ 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
