Dave Cridland [Home]
dave at cridland.net
Thu Apr 29 15:10:19 EEST 2004
On Wed Apr 28 23:45:55 2004, Waldo Bastian wrote:
> On Thu April 29 2004 00:08, Dave Cridland [Home] wrote:
> > Actually, looking through the documentation for KConfig, the hardest thing
> > to solve seems to be its ability to base defaults on the result of a chunk
> > of C++. That's pretty wild stuff.
> That's code that gets compiled into the application and it basically just
> means that the applications determines the default at runtime. Our
> meta-format essentially describes the application settings used by the
> application, but the application doesn't use this information at runtime,
> it's already incorporated in the application.
I guessed that, but it's nice to have it spelled out, thanks.
> I believe that this is different with GConf, can anyone confirm / deny that?
Yes, I think I've sufficient knowledge, just about, to confirm that. Defaults
are specified by schemas, which can hold a different default for every
locale, as well as documentation for the key. (There's nothing mandatory
about a Schema, it's essentially documentation only, apart from the defaults.)
Keys point to schemas, which are themselves keys. I've never actually looked
to see if schema keys have a schema themselves. :-)
So loosely, on a key, you have the following metadata:
Value, Type, Schema, Rights.
Value and Type are hopefully obvious. Schema is essentially a GConf path to a
key with a Type of Schema, whose Value holds the Schema for this key.
Schemas consist of an 'owner' (application name), a datatype name, and a set
of locale-specific data comprising of a default, a short-description, and a
Rights are restricted to Read and Write, and may be assigned globally by the
backend - in practise, a backend is read-only or read-write.
GConf uses multiple backends, and stacks them, generally using three, using
the highest available one to get/set values. Typically, these three are 'Site
Defaults', 'User Settings', and 'Mandatory Settings'.
For comparison, ACAP uses no schemas - the semantics of the entries and
attributes which should be used are instead denoted by the dataset class name
(part of the heirarchy), which hopefully references either a dataset class
defined in an RFC (There aren't any, but plenty in draft), or a vendor's
vendor or product specific namespace.
Metadata on an entry is held in special attributes, and includes a
modification time. Metadata on attributes is also held, and includes
'attribute' (The attribute's name), 'value' (The value, or values), 'size'
(The size of the value, or sizes of the values), 'acl' (The ACL - unclear if
this is intended to be the ACL in effect, or a specific ACL for this
attribute if one is set), and finally 'myrights', a server calculated list of
Rights in ACAP include Read, Write, Administrate, Insert (STORE on a
previously NIL value - in theory, all possible attributes exist and are NIL
on any given entry), and Search (Defined somewhat oddly, but generally taken
to mean the value will always fail any search)
Instead of GConf's stacked backends, ACAP uses 'inheritance', effectively
meaning the same thing, except that any dataset may specify the previous one
in the stack, if any. Mandatory defaults are, in theory, handled by ACLs set
on inherited attributes, but this is proving to be a bit of a problem for me
right now, especially trying to let people change their inheritance sanely.
How ACLs interact with inheritance is entirely unmentioned by the
Hope all this helps.
More information about the xdg