[Kde-kiosk] [RFC]: KConfigSQLBackend

[Ralf Nolden]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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
> konqueror)
>
> 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 ?

Ralf
>
> Cheers,
> Waldo

- -- 
We're not a company, we just produce better code at less costs.
- --------------------------------------------------------------------
Ralf Nolden
nolden at kde.org

The K Desktop Environment       The KDevelop Project
http://www.kde.org              http://www.kdevelop.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+cayju0nKi+w1Ky8RAtdPAKCDZTtViXynfrxixjBInwC6elt22ACeKnOT
i2TQWcmq2KvpT8N3/vvkuto=
=bmaM
-----END PGP SIGNATURE-----