Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Global plugins return values #2807

Open
kodebach opened this issue Jun 24, 2019 · 4 comments

Comments

Projects
None yet
3 participants
@kodebach
Copy link
Contributor

commented Jun 24, 2019

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:

elektraGlobalGet (handle, ks, parentKey, PREGETSTORAGE, INIT);
elektraGlobalGet (handle, ks, parentKey, PREGETSTORAGE, MAXONCE);
elektraGlobalGet (handle, ks, parentKey, PREGETSTORAGE, DEINIT);

@kodebach kodebach added the bug label Jun 24, 2019

@mpranj

This comment has been minimized.

Copy link
Member

commented Jun 24, 2019

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.

@kodebach

This comment has been minimized.

Copy link
Contributor Author

commented Jun 24, 2019

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.

@markus2330

This comment has been minimized.

Copy link
Contributor

commented Jun 24, 2019

Yes, I fully agree with @kodebach. In the positions for validations, we definitely need to abort.

@mpranj

This comment has been minimized.

Copy link
Member

commented Jun 25, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.