DConf configuration system

[Avery Pennarun]

On Wed, Apr 06, 2005 at 11:18:23AM -0400, Sean Middleditch wrote:

> Why should it have folders and all that?  It really shouldn't be
> anything more than a key/value database.  The keys might look something
> like UNIX paths, but that doesn't mean they are - the engine doesn't
> need to specially recognize the / character or anything.  Making it
> actually folder-based doesn't buy you anything, but it could potentially
> complicate backend code.
> 
> Instead of setting properties like access privileges and such per folder
> or per key, you could do it using patterns.  For example, a rule in the
> system configuration could state something like:
>   # admin can edit panel config, users cannot
>   /app/gnome/panel/*: root(rw),*(ro)
> That then would just be something compared with any keys using fnmatch
> (or something similar).

Unfortunately this won't work, because it doesn't let you do non-recursive
iteration through the tree.  As the simplest example, imagine I'm building
an app like gconf-editor, and my config tree contains only 10 toplevel
folders but 100000 keys (not an unreasonable number, unfortunately, which I
am quickly learning as UniConf becomes more popular).

How do I use a wildcard match to say "give me only the list of toplevel
folders" so I can navigate the tree incrementally?  You could do it with a
regex, but having the backend actually *implement* the regex would require
it to linearly search the complete set of 100000 keys... unless someone has
invented a "regex hashtable" algorithm or something I haven't heard about.

I can tell you with 100% certainty that non-recursive iterators over a list
of keys are extremely important to a configuration system.  (Recursive
iterators are also extremely important, but slightly less so.)  And
implementing a path system is actually quite painless.  Especially if you
use '/' as the separator, you even have the option of using the Unix
filesystem itself as your backend (which is what Elektra does).

Have fun,

Avery