ben at meyerhome.net
Thu Mar 13 17:25:22 GMT 2003
> Currently, it seems like in order to support this new class we would only
> need to build a KConfigSQLBackend class that handles this data structuring.
> In order for a KConfig object to use this class, we need the ability to
> tell it to use this new backend instead of the KConfigINIBackend, perhaps
> via a new constructor. Hopefully, everything else will "just work".
I would think that if you had multiple ways to store the settings (xml, ini,
db) you wouldn't want to have each application choose which one to use, but
have a kconfig option (hehe, but what format would that be in...j/k). Maybe
have the choice compiled in or have a file that contains which settings
system to use. That way KConfig would handle it internally and every
application would automaticly use it. Then you could also have x number of
backends in the system without breaking bc. The ini system would be the
default, but with an edit of a file, KConfig could be set to use xml or db
etc. We would probably want to have the ability to load two backend systems
at once when migrating or even some sort of automated migration built in
(load ini system and db system, load all ini settings, save in db).
More information about the kde-core-devel