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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list