bastian at kde.org
Thu Apr 29 17:29:53 EEST 2004
-----BEGIN PGP SIGNED MESSAGE-----
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
> 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?
bastian at kde.org | SUSE Linux 9.1 Order Now! | bastian at suse.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the xdg