[Kde-kiosk] [RFC]: KConfigSQLBackend

[Caleb Tennis]

=46rom 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=20
database is becoming more and more important.  One such benefactor of this=
=20
setup, for example, is the KDE Kiosk project.  It may be desirable for an=20
administrator who handles multiple machines to keep configuration files=20
centralized in one place.

The proposed correlation between INI config and SQL config set up as follow=
s:

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

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

Each table has the following columns: id, key, group, element, data,=20
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 configuratio=
ns=20
for the same entry in the same table.  For example, my company uses KDE at =
a=20
number of stations which are referenced by number.  By storing a numerical=
=20
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",""
=2E..


Implementation:

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

Currently, it seems like in order to support this new class we would only n=
eed=20
to build a KConfigSQLBackend class that handles this data structuring.  In=
=20
order for a KConfig object to use this class, we need the ability to tell i=
t=20
to use this new backend instead of the KConfigINIBackend, perhaps via a new=
=20
constructor.  Hopefully, everything else will "just work".

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

Aside from the obvious aspects, like maintaining BC, would anyone like to=20
generate comments about this concept?  I'm hoping that the utility of havin=
g=20
this function will allow me to integrate it with KDE while violating the=20
"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)