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