D-Conf (my first conclusions)

[Avery Pennarun]

On Sat, Mar 05, 2005 at 03:05:24PM +0100, Philip Van Hoof wrote:

> A generic configuration system that will be used by most desktop
> applications.

Yes.

> It needs to make it possible to "listen" for changes.

Yes.
 
> For many other minimum-requirements please read the other posts. Most of
> them are already implemented in the software "GConf".

It would be nice if someone would summarize them in one place, of course. 
(I'm too lazy right now, and I'm willing to admit it :))

> What isn't needed or perhaps needed but not in the scope of a project
> like D-Conf
> 
> People have to understand that the "D" in D-Conf means "Desktop". Not
> "Dude this can do everything". It's a Desktop Configuration management
> system. It wont be started during the bootup of a computer system. It
> shouldn't be used for system services like a webserver or an MTA. It
> shouldn't be used to alter the tweak-settings of your kernel.

I disagree with all these things, in a minor way: they shouldn't be
*antirequirements*, they should be "might be nice" requirements.  Don't
build a system deliberately to not allow these things.  Simply build a
system that may or may not work with these things, whichever is more
convenient.  And if your design *could* do these things with a couple of
minor tweaks, make those minor tweaks.

I've just spent a bunch of emails trying to demonstrate that those minor
tweaks are really easy, so it would be terrible to make an architectural
decision that would prevent these things from working.

> At this moment there's plenty systems and softwares available to convert
> existing system-application configurations into a
> database-with-triggers. There's no need to redo all this. Sure people
> need it. But it isn't the desktop application developers nor the desktop
> applications itself who are in need of it.

Okay.  One of your requirements should be "don't duplicate that effort."
Another should be "consider allowing these people to store their stuff in
your system if it makes sense to do so."

> Also, D-Conf wont magically make system configuration easer to manage.

Yup.  Okay, well, maybe slightly easier, but certainly not the way that some
people want.  (For example, a networked config repository could make it
"easier" to deploy whole clusters of machines.)

> It will even put an extra needless layer on top of the current
> situation. Neither the system administrators nor the desktop users are
> in need of it nor want this.

If you remove the word "needless", and the claim that nobody wants this, I
agree.  Me (developer/sysadmin) and my users (sysadmins/users) want this, so
you're already at least partly wrong.  And if it does something useful, it's
not needless.

> The configuration of your bootup is mostly in hands of the packagers and
> your distribution. In fact it shouldn't be alterable by a normal user at
> all. And for that single case "configuring which of the system-services
> are to be started upon startup" we shouldn't base an entire
> configuration management system on the possibility to do that. There
> easer ways to get that configurable by the user.

Right, the system absolutely should not be based on that.

The quick version of the only requirement is "Would be nice: the ability to
run this config system before /usr is mounted.  This implies few
dependencies on big libraries, and extreme ABI stability, and that using a
separate daemon should be made optional if that can be done easliy."

Have fun,

Avery