[Kde-kiosk] [RFC]: KConfigSQLBackend

[Ralf Nolden]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Donnerstag, 13. M=E4rz 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 on=
ly
> > need to build a KConfigSQLBackend class that handles this data
> > structuring. In order for a KConfig object to use this class, we need t=
he
> > 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 fr=
om
> local disk. The advantage of this approach would be that it might also wo=
rk
> 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 configurat=
ion=20
with CVS and have a gui that allows him to customize the whole desktop=20
settings. Where we're back at kconfedit in kdenonbeta :-) Maybe if a test=20
implementation is in place kconfedit can be extended so it makes

=2D - kiosk mode configuration easier
=2D - create a CVS module for the admin
=2D - pull/push cvs commits to the SQL database=20

Another possibility would of course be that the admin only works on the CVS=
=20
version while there would be a sync mechanism for the cvs update directly=20
into the database.

Any ideas ?

Ralf
>
> Cheers,
> Waldo

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

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

iD8DBQE+cayju0nKi+w1Ky8RAtdPAKCDZTtViXynfrxixjBInwC6elt22ACeKnOT
i2TQWcmq2KvpT8N3/vvkuto=3D
=3DbmaM
=2D----END PGP SIGNATURE-----