Configuration API

[Dave Cridland [Home]]

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 
long-description.

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.

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 
specification, irritatingly.

Hope all this helps.

Dave.