Elektra backend for KDE
zack at kde.org
Tue Feb 21 22:47:08 GMT 2006
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
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
> > 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
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 :)
Seen it all, done it all, can't remember most of it.
More information about the kde-core-devel