Klemens Böswirth

> It should be quite easy to do compared with other projects? Calling this "easy" is a bit of a stretch... It might be easier than _some_ other projects, but...

As an extension to the more common formats above I'd like to suggest: https://kdl.dev/ It's hierarchical, supports multiple values per node (= arrays) and nodes can have additional named properties...

I think currently there is no mechanism to load additional plugins, if `KDB_DEFAULT_STORAGE` has a dependency (e.g. `base64` or `directoryvalue`). I think this is not a problem right now, but...

I think the TOML plugin should be sufficiently complete to try using it as the default again.

@markus2330 Do we really want to try making TOML the default before the new backend system (#3693) is done? AFAICT the only way to do this is to create a...

> TOML is much more popular than dump, so if we can avoid presenting dump to newcomers would be a big gain. Totally agree, but the metadata issue in `toml`...

No, I'm not working on this anymore. I unassigned myself from this and any other issue where I think somebody else could help out. > I think this could be...

I don't think the parsing part is the hard part of this issue. In some cases it might be tricky, but flex/bison is well documented and there is a lot...

As @markus2330 said, it's not just about renamed keys. The decision is in general: **Which version of the KDB should be used for notifications/change tracking?** Currently we use the version...

> Probably some restrictions of what plugins are allowed to do are necessary. I've been advocating for this for years now (e.g. https://github.com/ElektraInitiative/libelektra/issues/3497#issuecomment-704206352) and was always shot down... Now that...