Klemens Böswirth

> `infos/features` might be extended to other types, though. I think we should use separate keys, e.g. `infos/features/storage` and `infos/features/type`. Otherwise will just end-up with the same mess as `infos/status`,...

see also #3504

> usage of thread safe functions everywhere Yes, that seems like a pretty good showcase example. > Imho the most important problem is If you're using TOML and see it...

Moved to https://github.com/ElektraInitiative/libelektra/issues/4870#issue-1620377910

Moved to https://github.com/ElektraInitiative/libelektra/issues/4869#issuecomment-1465208310

Generally speaking, implementing this in #3693 shouldn't be a huge problem. A few comments of the top of my head (in no particular order) - I assume, the solution here...

> If the admin has some way to ensure to get what (s)he wants, such limitations are maybe not necessary. If the admin does not impose any restrictions it would...

> Can you sum up what we talked about in the decision of #3693? Will do

The part about reading `user:/elektra/mountpoints` and `dir:/elektra/mountpoints` could be implemented as part of #3693 yes. The rest, especially the resolver changes should probably be a separate PR after that.

Yes, would be great, but doesn't fit with my thesis topic at all and I don't have unlimited time.