Hi,<br>
<br>
I'm working on a new KConfig backend for KDE using libelektra<br>
(<a href="http://www.libelektra.org">http://www.libelektra.org</a>). You can find the patch in elektra SVN<br>
(patches/kconfig). Its still in a "work in progress" state but most<br>
things works.<br>
<br>
During this work, i see current kconfigbackend design doesn't allow<br>
(easy) creation of backend which doesn't rely on files (like SQL, LDAP,<br>
...). IMHO, the actual design have two major issue :<br>
<br>
* KConfigBackEnd::changeFileName: This method change the resource type<br>
and filename for the current KConfigBackEnd instance and thus, it<br>
doesn't allow to select another back-end to parse this new<br>
resource/filename (since its done in the backend itself).<br>
 The problem is that doesn't allow to have "partial" backend : backend<br>
which are used only for some combinason of resource type and filename.<br>
You have to write a backend which is able to manage everything (that<br>
include absolutle filename too, which is near an imposible case for a<br>
non-filesystem backend). In few words, actually you cannot have kde<br>
configuration managed by one backend while other stuff are by other. Its<br>
why i think changeFileName (rather than call a KconfigBackEndFactory in<br>
the KConfig constructor) should be able to select a backend dynamicly<br>
accordingly to the resource type and configuration filename.<br>
<br>
* lockFile & checkConfigFilesWritable: These methods are backend's dependends<br>
and shouldn't be implemented in the KConfigBackEnd parent class. i.e: In a SQL<br>
backend, lockFile could be implemented as a row locking.<br>
<br>
The solution i found add somewhat a "new layer" : KConfigParser. KConfigParser<br>
are mainly like "old" KConfigBackEnd but allow specific implementation for<br>
methods lockFile & checkConfigFilesWritable. So the "old", KConfigINIBackEnd<br>
is now a KConfigINIParser.<br>
<br>
KConfigBackEnd is now a wrapper class (and keep the same API) which<br>
implement only one method: changeFileName. This method call a KConfigParserFactory<br>
for create dynamicly the parser. Others methods (parseConfigFiles(), sync(),<br>
checkConfigFilesWritable(), ...) act as wrapper for the created parser.<br>
i.e :<br>
<br>
        KLock KConfigBackEnd::lockFile(bool bGlobal)<br>
        {<br>
                if ( mParser )<br>
                       
mParser->lockFile(bGlobal);<br>
<br>
                // send some error here ...<br>
<br>
                return 0;<br>
        }<br>
<br>
These changes provide an easier (or, at least, a possible) path for writting new<br>
"KConfigParser" which doesn't rely on files and without make huge changement<br>
nor have to change the current KConfig/KConfigBackEnd API.<br>
<br>
Patch for kdelibs-3.5.2 including these changes can be found on the libelektra SVN:<br>
<a href="http://www.germane-software.com/repositories/elektra/trunk/patches/kconfig/kconfig-elektra.patch">http://www.germane-software.com/repositories/elektra/trunk/patches/kconfig/kconfig-elektra.patch</a><br>
<br>
Comments about that are welcome !<br>
<br>
Regards,<br>
Yannick.<br>
<br>