Requirements for Key Names

[markus2330]

We discussed a lot about potential restrictions or semantics in key names but did not look so much at which requirements applications actually have.

@mpranj Can you collect the requirements for KDE&GSettings?

From a quick look KDE is quite demanding, it has:

• @ in kopeterc for identifiers of Jabber addresses in the section names
• $ to start special sections, in particular [$VERSION] across many different config files (e.g. knotesrc, kdedrc, kwinrc, ...)
• # for arrays, but with prefix, e.g. [Identity #0] or [Filter #0] and many other places, e.g. for kmailrc and emailidentities. Furthermore for section names in katemoderc: [C#]

I did not check, though, if this is only in the config files, or if these characters go up the whole API.

[kodebach]

Can you please provide links to where you found these requirement. I don't use KDE and have absolutely no idea how its config formats work. Google sadly doesn't give any useful results for e.g. kmailrc.

Based on my experience with LCDproc, I would say we can't be directly compatible to existing configs, or we need special plugins to convert these KDE/GSettings configs into something that is usable within Elektra. This of course would also mean changes on the side of the applications.

---

Regarding arrays: Are the names of sections like [Identity #0] or [Filter #0] actually used? Do they actually mean something to KDE or are these just arbitrary names that could be replace with [foo] and [bar] without breaking anything?

I suspect the section names might be arbitrary (or maybe just the Identity and Filter part have meaning) and the actual information (ids, display names, etc.) is contained only in the key value pairs of these sections.

For @ and $: Do these actually have meaning or are they just part of the name and only there to make the sections more distinct from the rest?

[markus2330]

I found these requirements by looking at config files I am using. I am afraid this is not documented anywhere.

Would be interesting if they mean something but to find this out, we need to dive into the source code.

@FelixResch @darddan did you maybe already find out something about this?

[darddan]

Afaik the keys could contain anything as long as they're not closing tags or equal signs. This information must be in the https://github.com/ElektraInitiative/libelektra/blob/master/src/plugins/kconfig/README.md.

Independent of what KDE official apps use for their keys, the parser in KConfig is really forgiving and doesn't restrict much for the key names. I assumed that the Elektra version shouldn't add restrictions just in case someone made use of special characters in the past.

Those keys should still be accessible in the same way using the Elektrified version of KConfig.

[kodebach]

@markus2330 @mpranj What is our opinion on limiting the length of a key name part?

Most file systems limit the length of a filename to 255 bytes/characters. I think key name parts longer than 255 don't make much sense in Elektra, so we could enforce a limit. The limit may allow some optimizations in the future.

Also AFAIK the Linux VFS imposes the 255 byte limit on all filesystems, so an Elektra FUSE implementation would definitely have the 255 byte per key name part limit.

[markus2330]

I am against any arbitrary restrictions. For file systems it makes sense, as they have persistent structures where some relocations would be very expensive. We do not have such restrictions and as such we should not add them.

I also do not see any relevant optimizations we could do with lengths restrictions. We can have union {char*, char[255]} in cases where 255 is enough most of the time and only do dynamic (re)allocations if it is not enough.

It is actually a real requirement that key name parts can be more than 255 bytes long. E.g. kilerc has following section names:
[Document-Settings,URL=file://<<filename>>] where <<filename>> is a full filepath which can be 255 bytes long 😉

I am looking forward to @dev2718 work on FUSE, which will yield a full list of all restrictions file system semantics would have for configurations. The list is basically an advertisement for Elektra. Nevertheless, I think the FUSE binding will be very handy in practice, as these restrictions will probably only apply in rare special cases (e.g. inability to have two files where the first 255 characters are the same) as the FUSE implementation will have a KeySet with full information anyway and FUSE will be only a view on that KeySet (e.g. showing only the first 255 chars).

[mpranj]

@kodebach what would these restrictions enable us to do/optimize? I am a bit hesitant to add such restrictions if there are real requirements as @markus2330 pointed out.

I think having a union {char*, char[255]} is a really bad idea, unless you want to blow up the size of all Key structs above 256 bytes.

[kodebach]

kilerc has following section names:
[Document-Settings,URL=file://<<filename>>] where <<filename>> is a full filepath which can be 255 bytes long

Well that's just horrible config design... I hope URL is not decoded from the section and they just used it as a convenient way to get unique names.

I also remembered that we write the whole mountpoint parent key into one part in system:/elektra/mountpoints/ so limiting to 255 chars wouldn't work anyway.

FUSE will be only a view on that KeySet (e.g. showing only the first 255 chars)

Only showing the first 255 chars could cause collisions easily. There are other ways. Something similar to what Windows does to for 8.3 DOS filename compatibility or much simpler: "Any filename longer than 255 chars and any filename whose 191st character is an @ is truncated to 190 characters and we append an @ and the SHA-256 of the full filename as 64 hex digits".
Should be unlikely to get collisions with SHA-256.

what would these restrictions enable us to do/optimize?

I had some ideas for elektraKeyNameCanonicalize et al., but I'm not sure it would've had much advantage anyway.

I also thought "If you're using key name parts longer than 255 chars, you're doing it wrong", but it seems not everybody agrees on that.

[kodebach]

@markus2330 I think we can close this issue. Or is there still something to discuss?

[markus2330]

No, the current decisions cover all these cases.