Elektra backend for KDE

[Zack Rusin]

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:
>
> KDEPREFIX_CONFIG_FORMAT
> KDEDIRS_CONFIG_FORMAT
> KDEHOME_CONFIG_FORMAT
>
> 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.
>
> thoughts?

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.

Zack

-- 
All those who believe in telekinesis, raise my hand.