Closed markus2330 closed 3 years ago
spec does a cleanup then placed with the postget or preset cleanup placement though
@tom-wa yes, but its not yet done by the mount tool. We should first get consistent names, and then do the integration.
I have some questions regarding the hook names/semantics (from decisions/
).
Firstly, I have this table of placements. Some were not self-explanatory for me, marked with a ?
.
hook name | placement/semantics |
---|---|
prerollback | before rollback |
rollback | ? |
postrollback | after rollback |
getresolver | ? |
pregetstorage | start of kdbGet() |
getstorage | ? |
postgetstorage | end of kdbGet() |
setresolver | ? |
presetstorage | start of kdbSet() |
setstorage | ? |
precommit | before commit |
commit | ? |
postcommit | after commit |
Notes:
backend->getplugins[RESOLVER_PLUGIN]->kdbGet..
)?No, if something is missing, please add it to the proposal. Also if there are too many (which might be the case for the ones marked with ?), you can propose to remove them.
Rollback is for the case when one of the set-plugins failed. Docu is in elektra-algorithm.md and elektra-plugins-ordering.md (in doc/help).
About the exact placement: it is difficult to discuss it without code, maybe you can mark the positions in a PR for further discussions?
E.g. the commit
-phase is a done by plugin, the idea is to have a global hook before and after it. But I did not look into the details. Note that if a global hook is pre/post to some place is decided by /before
and /after
, not directly by its name -- as described in the decision.
One more thing: I misled myself into thinking that infos/placements
was where we would configure global plugin positions via contract.
I now realized that - I think - this is merely the configuration for the list plugin.
Should we add a new entry in the contracts for the positions of global plugins, or was the plan to configure them manually (i.e. setting the keys in system/elektra/globalplugins
programmatically inside the plugin code).
One more thing: I misled myself into thinking
Wait, not so fast ;)
infos/placements was where we would configure global plugin positions via contract.
No, you are right, currently that is the case. The kdb global-mount
looks at infos/placments. That it additionally uses the list plugin, is basically "implementation detail" so that more than one plugin per global placement can be used.
The backend mounting (kdb mount
) will later also be converted to use the list plugin. This brings some nice features such as lazy mounting without complicating the core even more.
From the global hooks point of view it does not matter if it is a single plugin or a list plugin. You invoke the function, the keyset might get modified and you get a return value in either way.
Should we add a new entry in the contracts for the positions of global plugins
If it is needed (ergo: a hybrid plugin that actually needs different plugins for global and backend placement), we can add it.
If kdb global-mount
honors placements from infos/placments, then I found a bug/inconsistency.
Take the dbus
plugin. It has infos/placements = postgetstorage postcommit
. Both positions qualify for a global position.
When I run kdb global-mount dbus
it mounts dbus only to the postcommit
placement, but not to postgetstorage
. (when I say mount I mean kdb export system/elektra/globalplugin
shows some configuration for it)
Cannot reproduce (at least not by looking at kdb export
), please open a separate issue for it (Ideally with some tracing plugin or similar showing the problem). Note that the list plugins gets added at all placements, that does not necessarily mean that that it gets executed for every placement.
I mark this issue stale as it did not have any activity for one year. I'll close it in two weeks if no further activity occurs. If you want it to be alive again, ping the issue by writing a message here or create a new issue with the remainder of this issue. Thank you for your contributions :sparkling_heart:
I mark this issue stale as it did not have any activity for one year. I'll close it in two weeks if no further activity occurs. If you want it to be alive again, ping the issue by writing a message here or create a new issue with the remainder of this issue. Thank you for your contributions :sparkling_heart:
I closed this issue now because it has been inactive for more than one year. If I closed it by mistake, please do not hesitate to reopen it or create a new issue with the remainder of this issue. Thank you for your contributions :sparkling_heart: