Libelektra: How to identify a "section"?

[domhof]

lcdproc uses the following two functions:

int config_has_key(const char *sectionname, const char *keyname);
int config_has_section(const char *sectionname);

For config_has_key we can easily provide a function that is a wrapper around keyIsBelowOrSame. For config_has_section however we need to differentiate between a key and a section. Does Elektra differentiate between keys and sections at all or are they essentially the same?

[markus2330]

Thus we only have a single key name (and no sections), only one function should be enough. INI can enforce to have keys present for sections, so checking if a key is present at the "section" will work (if this is really needed in the code?).

Elektra could differ by flagging "sections" using metadata but I see no benefit for this. We should have in mind that lcdproc might not want to have INI forever, so we should abstract from peculiarities of INI.

[markus2330]

@domhof Please assign questions/tasks or similar to https://github.com/ElektraInitiative/libelektra/projects/7 so that it is easier to track progress.

[tom-wa]

INI currently uses 2 flags: ini/internal/section and ini/internal/parent
the first marks a section key, the second adds the section/parent of each to key to itself.

i agree with both of you though, "sections" are too ini specific, but some generic hierarchical flags/metainfo would be practical since a lot of configuration files provide some sort of hierarchy and converting from one format to another would be more accurate that way

[markus2330]

The null keys is a structural element that indicates that there is a configuration setting, but it does not have a value. This sounded for me quite similar to INI sections but @tom-wa never liked it that way ;)

You can get the behaviour with the non-default NULL setting in the INI plugin. Maybe we only talked past each other and confused the statement "how to indicate a section" with the completely unrelated question if "sections should be created by default if there are keys below it".

In any case, I think we should make it consistent and the different section configurations should only tell weather sections are created automatically, not by which keys they are represented.

[tom-wa]

there were 2 issues with using NULL for sections:
1) if theres a spec key with a binary metakey that matches an INI key and the spec plugin copys the the metadata it messes up the INI structure
2) if you want a section key that also holds a string value (on my todo list) it gets ugly

thats why i switched to internal/ini/section (creating section keys using NULL keys still works)

[markus2330]

if theres a spec key with a binary metakey that matches an INI key and the spec plugin copys the the metadata it messes up the INI structure

Isn't this a bug of the spec plugin? It should clean up after all..

if you want a section key that also holds a string value (on my todo list) it gets ugly

Yes, that is a valid reason. But it is really a non-standard INI file then.

[tom-wa]

Isn't this a bug of the spec plugin? It should clean up after all..

you are right, i think the issue was the missing cleanup placement and is already resolved.

Yes, that is a valid reason. But it is really a non-standard INI file then.

true, we should rename the plugin and just mention that it also parses INI files :laughing:

[markus2330]

For Elektra's default storage we should not have such a feature bloat. It is somewhat nice that it is error-tolerant (especially for mountpoints: errors there would make kdbOpen unable to bootstrap any of the mountpoints), but the feature set should be minimal thus we need to support it for a long time.

@sanssecours Are sections also something needed somewhere else? (YAML?)

[sanssecours]

@sanssecours Are sections also something needed somewhere else? (YAML?)

Not that I know of.

[markus2330]

@sanssecours Do you need no metadata at all to distinguish between all the syntactical variants of YAML?

[sanssecours]

@sanssecours Do you need no metadata at all to distinguish between all the syntactical variants of YAML?

I am not sure, but currently I would guess that I do not need additional meta data. As far as I can tell the native data structures and the representation of data is decoupled in YAML. What syntactic format (representation) a YAML implementation uses to write data back to a file is up to the developer of said YAML implementation.

[markus2330]

Yes, of course it is always possible to wipe out the users syntactic choices and comments. It is only not so nice ;)

So when preserving everything, which kind of metadata would you use? Is there some intersection with INI, in particular the INI-section as proposed here?

The relevance is: someone of lcdproc considered to use YAML, so it would be great to have a migration path from INI to YAML for them.

[sanssecours]

So when preserving everything, which kind of metadata would you use?

I think preserving comments makes sense. For everything else, I think a sane default presentation is okay. Maybe we can also preserve some other details of the presentation later too, but this is definitely not on my list of priorities.

Is there some intersection with INI, in particular the INI-section as proposed here?

Not that I know of. YAML does not use sections at all. At least as far as I can tell.

[markus2330]

I do not know about the exact presentations in YAML, so maybe comments (that also contain new lines and so on) can preserve most of it anyway.

In general users a really picky if you change anything, sometimes even because of whitespace/tabs. (See discussions in #1375)

So during parser evaluation you should keep in mind how difficult it would be to map everything into the KeySet. Of course you do not need to actually do it during comparison of the parsers.