Elektra backend for KDE
zack at kde.org
Tue Feb 21 17:59:38 GMT 2006
On Tuesday 21 February 2006 18:41, Aaron J. Seigo wrote:
> i've already re-thought this over the weekend ... for now i'm just
> doing a simple "KDEDIR vs KDEDIRS vs KDEHOME" split. so $KDEDIR may
> be INI files, $KDEDIRS (yes, that would mean it would be all of them)
> may be LDB, and $KDEHOME may be something else. this will introduce 3
> new environment variables:
> this can obviously be set per user, so different kiosk profiles can
> have different settings for those env vars. this would probably only
> be of interest for KDEDIRS_CONFIG_FORMAT.
I think we had a discussion before about relaying on environment
variables too much in the past ;)
The question is whether there's a better solution here.
Do we consider the following scenario a problem: Kiosk settings are
being propagated from the backend specified in the environment
variable, user sets the variable to something that doesn't exists
(non-existing ldap backend, non-existing directory, whatever) and gets
control over the full installation. Is that an issue? If it is then
having a simple ini bootstrap the rest of the configuration system
would be a lot better solution. Distributing changes in environment
variables (for example in case we'll want to switch default backends)
is a pain in the ass.
But as far as configuration goes I still think KConfig needs work. We
need something that allows monitoring changes (in the same way that
right now we use DCOP to broadcast magic signals when something
changes) and has global knowledge of desktop configuration. GConf is a
lot better at this.
All those who believe in telekinesis, raise my hand.
More information about the kde-core-devel