caleb at aei-tech.com
Wed Mar 12 19:37:01 GMT 2003
* 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
Each INI file maps to a table in this SQL database (for example, a "katerc"
Each table has the following columns: id, key, group, element, data,
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:
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?
(pls CC me on replies)
More information about the kde-core-devel