[Kde-kiosk] [RFC]: KConfigSQLBackend
nolden at kde.org
Fri Mar 14 10:19:15 GMT 2003
-----BEGIN PGP SIGNED MESSAGE-----
On Donnerstag, 13. März 2003 00:52, Waldo Bastian wrote:
> On Wednesday 12 March 2003 20:37, Caleb Tennis wrote:
> > 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.
> Certainly, it will also make roaming easier.
> > 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.
> Does that first step make sense? I think you would like to be able to say
> on a KDE-wide scale "Use the SQL backend instead of the .ini files" I don't
> see the point of using this only for programs specially designed for it.
> As a bonus you will instantly meet the "2 programs rule" ;-)
> More seriously though, I would very much like to see an implementation of
> this. I'm especially interested in the performance part. I'm somewhat
> afraid that the solution that you outlined may be rather slow. I myself
> played with the idea to keep the INI-Backend but have a file-requester
> service that downloads and uploads config files when needed. The
> applications themselves would then still access the (downloaded) files from
> local disk. The advantage of this approach would be that it might also work
> for files that aren't strictly config files (e.g. the history file of
> Anyway, I would like to see this ending up in CVS
Me too. Killer would be if the admin could actually maintain the configuration
with CVS and have a gui that allows him to customize the whole desktop
settings. Where we're back at kconfedit in kdenonbeta :-) Maybe if a test
implementation is in place kconfedit can be extended so it makes
- - kiosk mode configuration easier
- - create a CVS module for the admin
- - pull/push cvs commits to the SQL database
Another possibility would of course be that the admin only works on the CVS
version while there would be a sync mechanism for the cvs update directly
into the database.
Any ideas ?
We're not a company, we just produce better code at less costs.
nolden at kde.org
The K Desktop Environment The KDevelop Project
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the kde-core-devel