LinuxRegistry in Freedesktop & KDE

[Duncan Mac-Vicar Prett]

El Friday 16 April 2004 09:26, Sean Middleditch escribió:
> GConf is moving in the other direction as its been shown that all those
> little files are very innefficient; most apps want to read *all* their
> keys, not just one or two.  Reading them all when they're one per file
> is very slow/inefficient, especially if you have more than a handful of
> keys.  (Like most real-world applications would.)

You are thinking in desktop apps. Yes, you're right. But we have to consider 
those console apps and small utilities/daemons/servers/tools.... they should 
not have hundred of keys.

> It also seems to lack change notifications, which means it's only useful
> for very simplistic applications.  If you edit the keys while the app is
> running, your edits will probably just be over-written.  Any
> configuration keys which need to be shared among different apps won't
> work very cleanly without adding a wrapper daemon.  So we'd need to
> write and standardize on one of these, as well, which would be a lot
> more work than the basic file backend, which is really all Linux
> Registry is...

Again, true for a desktop application. You could implement notifications in 
the GConf layer using this scheme. For old applications, it will be no worse 
thn the current /etc scheme, but in a consistent way, better for 
configuration tools. 

> I also don't see a clean way of managing system defaults or lock-down
> (other than write-protecting files).  All in all, this software doesn't
> seem to be much more than a wrapper for reading in the data of a set of
> files in a tree.  Nothing particularly earth shaking or interesting
> given how many problems it fails to even attempt to solve.

The target is again, consistency and a common format. Other solutions should 
be resolved in a upper layer. The guy says he is open to suggestions and 
improvements. But its easy to see that it must be simple if you want it to be 
a solution at a system level, like GConf, who can't provide that because its 
design and dependencies.

Duncan