Configuration API

[Waldo Bastian]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu April 29 2004 13:04, Dave Cridland [Home] wrote:
> > * Read values from the config.
>
> What's a value?
>
> It might sound like a pretty obvious thing to answer, but consider the
> current prior art a bit:
>
> Avi, for LR, advocates that everything should be a string.
>
> GConf supports a handful of fundamental datatypes, plus lists of any of
> them, plus pair of any two.
>
> KConfig supports stuff like expandable paths and all sorts.
>
> ACAP supports structures, but the members can only be strings, or
> (technically) unordered lists of strings. (I say technically - an ACAP
> server is allowed to reorder multivalues attributes on a STORE, however,
> none of them do. A search must be consistent on the order it produces, so
> there's little value I've seen.)
>
> So there you are - four different configuration systems, four different
> concepts of what a 'value' is.

At the storage level, KConfig considers all values utf-8 strings. When the 
application asks for the value it specifies the desired type and only then 
will the value be converted to that type. With KConfigXT we generate code for 
the access methods so that we get type-safety from the compiler based on the 
type specified in the meta-data. In both cases the backend has no actual 
knowledge about the type.

> Apart from all that above, GConf has supported atomic changesets for a
> while, but it's a little used feature - does this have to be mandatory to
> support? (I don't think so.) ACAP also supports this. I'm guessing LR does
> not, and I have no idea about KConfig.

All updates to a single file (our highest grouping level) are atomic in the 
sense that they all fail or all succeed. KConfig gives basically no 
guarantees for read-modify-write cycles, (in particular, if two processes try 
to add 1 to a numeric config entry, the end result will either be +1 or +2) 
in KDE 3.3 we hope to improve that and offer optional atomic support for such 
cycles as well.

> Finally, do we allow a conditional store: 'change this, but only if it
> hasn't been changed by anyone else'. GConf doesn't, ACAP does.

What are you going to do if it has? Provide the user with Bugzilla style 
midair collisions? I guess it is a good alternative for locking because I 
don't think it is a good idea to hold locks on entries pending user 
interaction.

> Oh, and, of course, is 'set this key to default' the same as 'erase this
> key' - ACAP says no, GConf says yes.

KConfig says yes as well.

> And we've still not got to whether a key can also be a directory - ACAP
> insists it always is, GConf appears to leave the decision to a backend
> (although I don't know of a backend that allows for a key to be a
> directory), and KConfig appears to insist a key is distinct from a
> directory. (My loose understanding is that all KConfig entries exist on a
> single level of the heirarchy, which does not allow for groups.)

Its a fixed file->group->entry hierarchy. I'm considering to add the 
possibility of additional levels of groups, I'm still undecided if in that 
case the entries and sub-groups in a specific group should share a single 
namespace, I'm inclined to keep them separate and allow for:
file/group/foo   -> entry named "foo"
file/group/foo/  -> sub-group named "foo"
file/group/foo/bar -> entry named "bar" in sub-group "foo"

But if other configuration systems would have problems with that, then it's 
probably not such a good idea. If they share the same namespace then it 
should be trivial to treat a sub-group as a single entry, by transforming it 
into a flat representation of the sub-group. Is that what ACAP does?

Cheers,
Waldo
- -- 
bastian at kde.org  |   SUSE Linux 9.1 Order Now!   |  bastian at suse.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQFAkRFhN4pvrENfboIRAn69AJ9tGadSxZI4BQ1yJbydfx73pfDTRACbBm7C
2QUYz0eK+4b2ziDhD/Lx2vo=
=WWon
-----END PGP SIGNATURE-----