kdb high-level API: global mode

[markus2330]

While I am against using globals at all, I see that many applications do not care and prefer a simpler API.

For the high-level API we could add an optional global mode, whenever the user passes 0 instead of the handle. For example:

kdbhlOpen("/sw/amazing/app/#0/current"); // also remembers the handle globally
...
kdbhlGetInt(0, "key"); // use global handle
...
kdbhlReload(0); // reload config using the global handle
...

Drawback: On multi-threading this obviously wont work and we would even produce race conditions if kdbhlOpen is used concurrently.

Alternative:

1. two different APIs, one with handle, one without.
2. its the applications problem how to pass the handle (how can we do it in lcdproc?)

@tom-wa @domhof What do you think?

[domhof]

Another alternative would be to provide two convenience-functions like kdbhlSetShared(KDBHL * kdbhl) and KDBHL * kdbhlGetShared() to store and get a shared KDBHL instance.

[markus2330]

Yes, this would make the feature more explicit. But maybe we implement such two functions within lcdproc? (They are really trivial)

[markus2330]

We should not use 0, it really confuses.

We could also have some ELEKTRA_INSTANCE`, but it makes the names really long:

elektraGetLong (ELEKTRA_INSTANCE, "CFontz/Size/Width")
elektraGetLong (ELEKTRA_INSTANCE, "CFontz/Size/Height");

elektraGetCFontzSizeWidth(ELEKTRA_INSTANCE);
elektraGetCFontzSizeHeight(ELEKTRA_INSTANCE);

[markus2330]

@tom-wa Can you check if we are able to pass a handle to every place where config is needed in lcdproc? Maybe there is no need for a "global mode" anyway.

[tom-wa]

usually i avoid global variables but lcdproc uses a global variable and i would keep it that way (at least for now).
i'd really like to provide 2 versions for lcdproc though (one with passing the handle, one using global variables) and let them decide which version they prefer.

[markus2330]

usually i avoid global variables but lcdproc uses a global variable and i would keep it that way (at least for now).

So it is not easily possible to pass the handle to everywhere needed?

i'd really like to provide 2 versions for lcdproc though (one with passing the handle, one using global variables) and let them decide which version they prefer.

The handle is definitely the better option (future-proof, e.g. if they want to introduce multi-threading), so if there is a way to do it with handle, we do not have to bother them about that question.

In particular, we have too many variables:

• handle yes/no
• error handling up-front/during getters
• code generation yes/no

We need to reduce the number of variants, ideally to code generation yes/no as only option for them. Otherwise inconsistent use of our APIs will creep into their code base.

[tom-wa]

For the server part it's easy, you just need to pass it, for some clients it seems like theres a bit more to change.

[markus2330]

Which are the problematic clients? We could also add a global variable only in clients where the change wouldn't be easy.

[markus2330]

not needed -> rejected