mount type by default

[markus2330]

The "type" plugin implements essential semantics, thus it should always be present except for spec (where it would always fail as the keys might not have values/defaults, see #2723)

[stale]

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 💖

[stale]

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 💖

[markus2330]

@kodebach what do you think?

[kodebach]

We can think about it in #3693. Since type is not designed as a global plugin (although it could be rewritten), the decision of mounting it by default would lie with the concrete backend plugin not with libelektra-kdb.

If we mount it by default, we may need to do some modifications too. For example, type = any is pretty useless, while type = string confusingly only accepts non-empty strings. I'm also still not a fan of the CORBA system. I have to think about which type is what every time. Maybe we should accept the more explicit C99 type names without the _t suffix (int32, etc.) as aliases.

There are also still the issues with normalization. Which I think can only be solved by different phases.

All in all, I think we should first finish #3693 and then we can discuss making type a default plugin.

[kodebach]

PS. IMHO the best solution would still be to integrate the type system directly into libelektra-core and libelektra-kdb, i.e. a Key can't just be string or binary, but can actually store a decoded value (e.g. int32_t) in addition to the string/binary data.

[markus2330]

Not only global plugins can be mounted by default, e.g. sync also gets mounted by default (for every mountpoint).

type = any is pretty useless, while type = string confusingly only accepts non-empty strings.

I agree that this is confusing, let us drop "any" and make "string" any string.

Maybe we should accept the more explicit C99 type names without the _t suffix (int32, etc.) as aliases.

Good idea.

There are also still the issues with normalization. Which I think can only be solved by different phases.

I think it is best if we disable such forms of normalization as they are not really a killer-feature and "origvalue" is confusing.

All in all, I think we should first finish #3693 and then we can discuss making type a default plugin.

It should be unrelated but I agree that we should not start too many tasks at once.

but can actually store a decoded value (e.g. int32_t) in addition to the string/binary data.

This is imho a pure optimization and brings many complications for bindings.

[kodebach]

Not only global plugins can be mounted by default, e.g. sync also gets mounted by default (for every mountpoint).

With the new system in #3639 it would be up to the backend plugin what is mounted by default and what isn't. For example in a database backend it makes no sense to mount sync.

I think it is best if we disable such forms of normalization

The normalization is required for the current high-level API and anything else that uses elektraKeyToBoolean (which only accepts 0 and 1 as valid values).

as they are not really a killer-feature

I actually think the normalization is a pretty good feature (when it works), because the application can be kept very simple, while the configuration is flexible. This is especially interesting, when a less strict format like INI is used. In formats with strict typing e.g. JSON the issue is less important.

and "origvalue" is confusing.

Yes, origvalue was a bad solution. There needs to be a generic solution that dispatches to all plugins that support normalization and this generic solution should be responsible for keeping track of original values and restoring.

This is imho a pure optimization and brings many complications for bindings.

Yes, it is a kind of optimization and bindings could ignore it entirely. They could just convert the string value again. However, this is exactly the problem with the current system. The type plugin validates that the string can be converted (and in the process actually does the conversion), but then applications have to do actual conversion themselves. This can lead to errors, if the application doesn't use the same conversion as type does.

The conversion functions elektraKeyTo* are already available in libelektra-ease, but I don't think many people know that and since they are not declared in kdb.h most people won't find them at first.

[markus2330]

With the new system in #3639 it would be up to the backend plugin what is mounted by default and what isn't. For example in a database backend it makes no sense to mount sync.

Yes, but probably it still makes sense to mount type. But this is only hypothetical anyway, for a longer time being there will be only one backend plugin and this should mount sync+type by default.

I actually think the normalization is a pretty good feature (when it works),

I agree but can't this easily be done post-1.0. Do you see any issues? (Assuming that 1.0 will have both a fixed kdb+plugin API.)

The conversion functions elektraKeyTo* are already available in libelektra-ease, but I don't think many people know that and since they are not declared in kdb.h most people won't find them at first.

Yes, we should advertise them better and we need a tutorial about types 😉, I added elektraKeyTo* in #280 (which already proposed that there should be a tutorial about types). Moving everything to the core might help short-time but will a huge long-term maintenance problem (e.g. if we decide to adapt to another type system).

[kodebach]

Do you see any issues? (Assuming that 1.0 will have both a fixed kdb+plugin API.)

In principle it should be possible to define a fixed API for 1.0 that can later be extended. Since backend plugins will be responsible for calling plugins and can define their own positions, the only relevant thing the kdb<->plugin API actually defines is when spec, gopts, et al. are called.

and we need a tutorial

I don't think tutorials are the solution to everything. I'd assume most people look at tutorials when they are new to Elektra. But once they are already using Elektra, they probably don't want to read tutorials aimed at beginners.

What we need is better discoverability. For the API, the docs and the website. I already know a lot about Elektra. Whenever I need look something up, I don't look at the docs. I read the source code, because I know I won't find it in the docs or on the website unless I check every file/page.

Tutorials are nice to get started with Elektra, or a part of Elektra. For example, if I want to add command-line options to my app, reading the tutorial for that makes sense. However, what if I'm already using gopts and want to e.g. look up how hide an option from the help message? Well I'd have to either a) know exactly where to look in the tutorial, b) read the whole tutorial or c) look at the source code.

IMO what we need is not tutorials, but more structured documentation, where I immediately know where to look when I need to answer to "How to do X?".

Moving everything to the core might help short-time but will a huge long-term maintenance problem (e.g. if we decide to adapt to another type system)

I mostly want some way to cache the decoded value inside struct _Key. It can be entirely agnostic to the type system and it would be fine if elektraKeyTo* isn't needed. As long as it doesn't do the conversion every time (especially for the high-level API this would be very nice). Binary metadata isn't allowed, otherwise that would be the solution.

[stale]

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 💖

[stale]

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 💖