DConf configuration system
ppatters at nit.ca
Wed Apr 6 22:37:28 EEST 2005
On Wednesday 06 April 2005 15:00, Jamie McCracken wrote:
> Avery Pennarun wrote:
> > On Wed, Apr 06, 2005 at 02:00:13PM -0400, Sean Middleditch wrote:
> >>Hmm, would it really be a problem for such an app (which would not be
> >>used very often at all by normal desktop users) to just grab all the
> >>keys? If it is a real performance killer (I'll trust your experience in
> >>this), then that would make "folders" necessary. With a real defined
> >>need, I have no further objections to them. :)
> > One example I can give is libnss-uniconf. When I run "id -a apenwarr",
> > it needs to look up the list of groups that "apenwarr" is in. Generally
> > (regardless of the actual layout of keys you're using) this will require
> > a tree iteration of some sort. Downloading the complete set of 100000
> > keys in order to display five of them will definitely make your "id"
> > command run much more slowly!
> Thats trivial for an SQL DB to handle. Indeed the B+ tree indexes in a
> DB will give you the fastest and most efficient filtering currently
> available for that.
> The fact that you are using one file per key in Uniconf will give
> terrible performance (due to large number of disk seeks) in general
> usage compared to a DB (which consequently minimises the no of disk reads).
> I realise Uniconf can use different backends (as do all the others) but
> I dont see your example as being a good reason to use it over others.
> If Uniconf is really suitable as a desktop config system then why are
> some of us looking into creating an alternative like DConf?
Actually, it uses whatever you tell it - it CAN use a "one file per key"
system, it CAN use an INI file, and it CAN use an SQL or even the Windows
Registry, or whatever GConf uses internally, or even an mbox, if that really
turns your crank - - the backends are already written for most if not all of
those. It is THAT flexible... (and complete :) - And that's the nice thing
about it - it doesn't tie you into anything other than what you already use -
remember the mantra of UniConf is that it is better than everything else
because it already subsumes everything else. If you've seen Avery's dog and
pony show that he's done at a couple of conferences, you realize that it is
already possible to configure KDE from GConf over DBUS using the Windows
Registry to store the Data (why you'd want to do that last, I have no idea,
but someone around here was smoking the crack pipe one day, and wrote the
Windows registry front and back ends for UniConf, so they are available :)
And your final question is what we've been asking ourselves for quite a
Net Integration Technologies R&D
> xdg mailing list
> xdg at lists.freedesktop.org
More information about the xdg