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