Elektra backend for KDE

[Zack Rusin]

On Tuesday 21 February 2006 21:11, Aaron J. Seigo wrote:
> On Tuesday 21 February 2006 10:59, Zack Rusin wrote:
> > I think we had a discussion before about relaying on environment
> > variables too much in the past ;)
>
> yes, for situations where third parties need to extend them at
> application installation time (e.g. XDG_*_DIRS). this is a different
> situation.

Well, this one is for our convenience. If we'll ever want to change the 
defaults (i'm sure we will) it'd be nice if it could happen 
transparently. 

>
> > 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?
>
> once they are set for the X session, they can't adjust them. they
> could get to a terminal and change them for applications run from
> that command line, but one can also block access to the command line.
> it's pretty safe in that regard.
>
> a global config file for this would be even more safe, and i did
> consider it, but that would result in more hits to disk (== slower),
> something i'm hoping to avoid as much as possible here.

It's not a big hit now and we're doing it for many apps/libs on kde 
startup too. 
And yeah, I am an environment variable hater. There's a combination of 
reasons for that:
a) they're never well documented,
b) semantics for changes to propagate down are always awkward (which is 
why everyone always restarts X and logouts which is dumb!)
c) when you have a configuration editor it's virtually impossible to add 
them to it so people won't see them
d) because of C, people coming to a system require extra inner knowledge 
of the system to be able to change them.

Some might argue that c and d are pluses because they make it more 
secure but they're not. Security through obscurity is never the right 
approach.  So yeah, I do prefer a global file that would be boostraping 
this system. Even if the contents of this file tells the thing to read 
its defaults from environment variables because then if I wanted to 
change my default config backend to ldap I could look "config backend" 
in my configuration editor and see an entry with description of where 
it's reading them from.

> > 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.
>
> yes. another item that helios and i have been discussing is the idea
> of location/network dependant settings.

Yeah, I tried to figure out how to do roaming profiles for a while. 
Everytime I came back to it, it required to change KConfig to have 
network aware backend which as you now know is not as simple with its 
current design :p Ian actually had a ldap backend at one point. The way 
we wanted to do that is have a priority list (in the same way KIOSK 
works) where settings propagate down. Which is basically what you seem 
to say so yeah, I'm all for that.

As for revision control, for KDE4 I'd like have basic support for 
_every_ file operation but that's a different discussion :)

Zack

-- 
Seen it all, done it all, can't remember most of it.