[RFC]: KConfigSQLBackend

[Caleb Tennis]

From kconfigbackend.h:

 * objects of this class. As of right now, the only back end available
 * is one to read/write to INI-style files, but in the future, other
 * formats may be available, such as XML or a database.

Having an alternative format for storage of configuration files, such as a SQL 
database is becoming more and more important.  One such benefactor of this 
setup, for example, is the KDE Kiosk project.  It may be desirable for an 
administrator who handles multiple machines to keep configuration files 
centralized in one place.

The proposed correlation between INI config and SQL config set up as follows:

A database is created where all of the configuration information will be 
stored.

Each INI file maps to a table in this SQL database (for example, a "katerc" 
table).

Each table has the following columns: id, key, group, element, data, 
attributes.

id: An incremental numerical id of that particular entry (primary key)
key: See below
group: The group which the entry belongs to
element: The name of the entry
data: The stored value of the entry
attributes: Miscellaneous attributes (immutable, for example)

The key column would allow a way to uniquely identify multiple configurations 
for the same entry in the same table.  For example, my company uses KDE at a 
number of stations which are referenced by number.  By storing a numerical 
number as a key, we can query the particular setup desired for that station.

As an example: From the kdeglobals file, I would have a table like this:

id,key,group,element,data,attributes
1,1,"General","alternateBackground","255,255,255",""
2,4,"General","alternateBackground","255,246,230",""
3,1,"General","background","214,205,187",""
...


Implementation:

I am currently using a local custom written class now to handle this data 
manipulation.  I would like to integrate it with the KConfig framework so 
that it's available to everyone.

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".

The first goal of this project is to just create an interface class that a 
programmer can use as an alternative for a custom written program.  However, 
as this concept matures, it may be desirable to integrate the use of this 
class with KDE's internal setup.  That can come later, however.

Aside from the obvious aspects, like maintaining BC, would anyone like to 
generate comments about this concept?  I'm hoping that the utility of having 
this function will allow me to integrate it with KDE while violating the 
"name 2 programs that use it" rule. :)

Any other kiosk folks out there that would like to use this class?

Thank you,
Caleb

(pls CC me on replies)