Status of gconf -> dconf

[Bastien Nocera]

On Mon, 2009-02-23 at 20:47 -0600, Callum Lerwick wrote:
> On Mon, 2009-02-23 at 17:17 -0500, Colin Walters wrote:
<snip>
> > Don't get me wrong - GConf has some very bad design flaws (at least
> > should have used something like Protocol Buffers instead of XML), and
> > I'm not defending the weird dconf licensing.
> > 
> > But "let's just use lots of files" is not the answer.
> 
> So group your keys if too many files is such a problem. You know, like
> we've been doing for decades. Config files are a Solved Problem, the
> only problem here is people want to write some overwrought universal
> library and make everything use it. While centralizing code is generally
> a Good Thing, people seem determined to overthink and overdesign it.
> Second system effect at its finest.

A modern configuration system needs:
- strong typing of values
- a way to set defaults and revert them
- changesets to avoid races
- notifications of changes
- protection against data loss when two applications want to edit the
same configuration (or configuration file)

So let's use less files isn't the answer. If you're designing a daemon
to be installed and administered by power users, go for it. Otherwise,
simple files in a tree is completely under-engineered for the desktop.
You need a daemon sitting on top of it.

> Everything not greppable, diffable, human readable and editable, should
> be dragged out in to the street and shot. This is /configuration/ we're
> talking about.

For GConf, we were human editable and readable through gconf-editor, and
greppable/diffable through gconftool-2.

Either you're fueling a flamefest, or you don't understand what's
required for a modern configuration system.

Cheers