Maybe there is an issue for this already, if so I couldn't find it.
kdbGet right now completely ignores the return values of global plugins. More specifically the return value of elektraGlobalGet is always ignored.
For example:
https://github.com/ElektraInitiative/libelektra/blob/3bd1553731c3707c5ff522b3a7e1fd968c47b5c8/src/libs/elektra/kdb.c#L1047-L1049
You're right. I added return values "recently" because I needed them for the cache. As for the other positions, the question is again the same: what are the semantics of some position, and what should happen in case of an error?
As an example: for the cache errors should be ignored and we treat it as a cache miss. If you need special semantics for your position, just check the return value. Otherwise we are running into the same meta-issue here: there is no specification what should happen, so everything is allowed.
For pregetstorage and more importantly postgetstorage we should have the same behaviour as for non-global plugins. If a global postgetstorage plugin like spec fails, kdbGet should fail, just as it would fail if a non-global plugin like type fails.
Otherwise global plugins can never be used for validation.
Yes, I fully agree with @kodebach. In the positions for validations, we definitely need to abort.
I'll do this (small fix) and update the proposal accordingly. I won't be able to rework the complete global plugins until my thesis is finished (priorities...). I suggest that we still discuss the semantics of the global plugins API and document them, so that it is clear what to expect and how to implement it.
@mpranj Are you working on this somewhere? Otherwise I will just include the checks I need in one of my PRs.
Are you working on this somewhere? Otherwise I will just include the checks I need in one of my PRs.
No, you can include the checks you need in a PR.
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:
Most helpful comment
I'll do this (small fix) and update the proposal accordingly. I won't be able to rework the complete global plugins until my thesis is finished (priorities...). I suggest that we still discuss the semantics of the global plugins API and document them, so that it is clear what to expect and how to implement it.