Configuration API

[Dave Cridland [Home]]

On Wed Apr 28 22:56:19 2004, Lars Hallberg wrote:
> Dave Cridland [Home] wrote:
> 
>> On Wed Apr 28 18:36:33 2004, Lars Hallberg wrote:
>> 
>>> Dave Cridland [Home] wrote:
>>> 
>>>> I'd prefer to see evidence that namespace clashes are a real and present 
>>>> problem, before splitting the namespace like that.
>>> 
>>> 
>>> I think it's an exelent idé, that kan give us a common way to access the 
>>> config without steping on eachothers toes!
>>> 
>> 
>> If there's an absolute need, then fine. But I can't see one, unless there 
>> are pre-existing namespace collisions.
> 
> The big win, as I see it is that anyone owning a domainname can put ther 
> config under the cheeme without hassel.

Yeah, I'd prefer that application developers had to think a little before 
throwing cooperation out of the window.

Bear in mind that it'll be the application developers themselves who come up 
with the shared configuration data standards, so it's a fine idea, IMHO, to 
let them have to think a little.

However, all that aside, please re-read what I've written. I'm happy if needs 
be that we forcably seperate out configuration at the top level, but if we 
don't need to, then we shouldn't. And I've yet to see evidence that such a 
seperation is required, and therefore I'm not advocating it. I've seen some 
evidence, in fact, that it's specifically *not* required, but certainly not 
exhaustive checks. Call me crazy, but I like to have a reason for a decision.

> 
> I see three uses (withot thinking to hard) for this api:
> 
> * Apps themself reading ther config. Apps don´t need this as they know ther 
> nativ format. But the win for the apps that do is that they esaly thru a 
compiltime switch can use diferent bakends, and gain network transparent 
config or whatewer. Only some apps need notifikation and the ability to 
update config.

Hopefully the applications will have no idea at all what backend they're 
using, and certainly not need a compile time switch. *shudder*.

> So the api shuld probably be split in diferent 'parts' (interfaces?), that 
> a backend kan implement some or all of, and that different apps and 
frontend can use some or all of.
> 
> At least this parts:
> 
> * 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.

Personally, I think translating into useful datatypes is best handled in 
> common code by the backend. I suspect the ultimate list of datatypes will 
be that of GConf with the addition of the Path and Enum types from KConfig, 
actually. Of course, the datatypes will 'smell' different in each, being 
QValueList<...> vs g_slist, etc. [Type names off the top of my head, thus 
probably wrong.]

We don't know how ACLs fit into this - do we insist that a user has rights 
through the directory structure in order to see a value, or do they bypass 
the rights on descent? I suspect LR does the former, with ACAP, it's the 
latter.

> 
> * Store values (and atomic sets of values).
> 

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.

We also don't know whether storing a key to a non-existent directory (In 
GConfesque - directory==group, key==entry for KConfig folk, I think) creates 
the intermediate directories or not. (I know ACAP does, but I've no idea 
about the rest, sorry.)

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.

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

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.)

> 
> * Aktivation of changes (tell postfix to reread its config).
> 

Quite definitely well outside the scope of discussion. Actually, there's two 
ways to go for this in any case:

1) A shepherd process which translates from the configuration datastore to 
postfix main.cf et al, and restarts/reloads processes as needs be.

2) Rewrite postfix. Which I really doubt will ever happen.

> 
> * Live notifikation.
> 

Again, a huge number of questions.

What's the definition of 'Live'? It's never instant, due to CPU latency if 
nothing else, so how far can we stretch the point?

Arguably, if we stretched it to breaking, but allowed an application to 
request all pending updates, we'd be able to include notifications of some 
level in the simplest of backends - they'd simply repoll when asked.

On the other end of the scale, GConf does a best effort at immediate 
notification - thus pending updates is largely a NOOP (just wait for any 
stores in progress to complete.)

ACAP, incidentally, operates a halfway house - it allows an implementation to 
'batch' notifications for a 'reasonable delay', which has been interpreted as 
30 seconds (By Cyrus SMLACAPd), and 'until the current transaction is 
complete, or we run out of buffer' by my implementation. (In other words, as 
near 0 as I could reasonably get it). ACAP does provide UPDATECONTEXT to 
force updates through.

Dave.