Mickael Marchand created a branch in KDE SVN to work on a KDE configuration storage system based SQL. This picks up the idea to have more ways in KDE to store the configuration than just having the file based way.
This idea to improve the current, INI-like file based storage system of KDE’s configurations was first made public by Aaron Seigo in January 2006. He suggested to use for a ldb which was/is used for Samba 4:
kde could get a centralizable, replicatable, scalable, fast and safe config storage system that can move us beyond ini-style configs without much work on our part. being able to store data in binary formats also means that we may find we get some performance boosts from not having to ascii-ize everything on the way out to the config file and repeat the process in reverse when reading it in.
As he later also made clear the idea was not to simply replace the current backend, but to write another one, to make them replaceable. And since kconfig was designed from the start as an API for different backends this idea was indeed quite realistic.
But nothing happened over the time until last Commit Digest’s Issue 72. There it was mentioned that Mickael started to work on a SQL backend:
API change in kconfig really basic SQL backend […]
and, the SQL backend, just a basic sqlite one for now (not even checking for locks/nb of connexions/… etc)till now, I was able to get kconfigtest to success all tests with the DB backend, and was able to run kwrite, modifying options etc
Besides a maybe faster configuration backend this work will truly abstract the configuration system and will make it possible to write others. So if you want to configure KDE in future with configuration system xyz – just write a backend for it. Think of possibilities like Elektra.
/home/liquidat 
I’m not knocking this idea but for years people have bitched about the Windows registry. How does this differ?
The structure of the Windows registry is hard to understand and hard to follow. Several places and keys are named in non-readable names, and there is no real way to easily access the database via command line.
And the same could happen to the SQL backed – but it could also be the other way. The SQL backend could store everything in a sane and user friendly way. And it could also come along with tools to access the data via command line.
In such a case the only thing both registries share is that both are stored in a binary format – everything else would be different.
Yes, I agree. The Registry was no human readable and it was too prone to breakage.
Wow. So there’s gonna be no more “vi ~/.kde5/config/whatever”? Gonna miss it…
“Wow. So there’s gonna be no more “vi ~/.kde5/config/whatever”? Gonna miss it…”
Why do you assume that the current method will disappear? The article makes it quite clear that having multiple, pluggable backends is the goal, and there’s no reason to assume that the current INI-style backend won’t be one of them.
“Why do you assume that the current method will disappear?”
Because “being able to store data in binary formats also means that we may find we get some performance boosts from not having to ascii-ize everything on the way out to the config file”. So the config files can’t possibly be human-readable, can they?
rufusD: the configuration system will have different backends. One backend will be able to store the data in binary format, while one backend will be able to store them in INI files. It will be up to you which backend to use/activate, so you can use your vim as long as you wish.
The other problem with the Windows Registry is that while it pretends to be a database, it really isn’t and breaks virtually every rule of ACID that you can name. A proper SQL driven backend would follow these rules or it wouldn’t be let in 🙂
why not have both binary and ASCII at once? you edit the txt files and KDE parses them into binary
Tortanick, while this might be technically possible I wonder where the benefit would be. Also, for all ideas you need someone who wants them so bad that he/she implements them.
The benefit is that you can still edit with text editors AND get the speed boost
Sure, but you can solve this by calling some scripts as well each time before/after you want to modify something manually. And that is definitely easier to design the system to keep different backends synchronized, I think.