[RFC]: KConfigSQLBackend

[Benjamin Meyer]

[snip]
> 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).

-Benjamin Meyer