Configuration API

[Lars Hallberg]

First, I'm not sure exactly *what* API we ar talking about her. But my 
understandin is:

config store -API- config deamon -API- protocol -API- app/config tool

that can be shortcuted (propably at compile/linktime) to

config store -API- app

Thats probably the best for apps to read ther own config (if they don't 
need notification). Replace 'config store' with 'backend' if prefered.

A config deamon is likly to talk to many backends, unless a compleet LR 
breakthru.

The protocol above is another pont of standardisation, but i find the 
API more important as it allow abowe 'shortcuting'.

Hopfully the Linux Conf 'midleware' can us tha same API to the backends, 
or eaven use another config deamon as backend!

Dave Cridland [Home] wrote:

> On Wed Apr 28 22:56:19 2004, Lars Hallberg wrote:
>
>> 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.

Cooperation take time. While agreing to a config format for bokmarks, 
email server setings etc apps have to work. I think apps will start to 
use comon standards as they mature, but it's no need to make life hard 
menwhile. And most apps vill need som extra private config for it's own 
featurs. If those featurs is good, and picked upp by more apps, they 
might be standardizised in the future. But I don't beleve it to be good 
if every new feature have to be standardizised befor the first 
implementation!

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

If this is *only* for desktop config shared by gnome and kde, ther might 
not be a need. But i think more like all config for all app.

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

Wheel, maybee a linktime switch.

And *if* You link in an bakend talking to a config deamon, You for sure 
shuld not need to worry about what backend that deamon is using. If You 
need notifikation, this is probably the only choce. Most likly - config 
tools use this path allso.

But other might prefere to link in a bakend (some staticly, some shared) 
that directly parce a given fileformat, and that is capabel only for 
reading config, and only that format. For an app reading its own config 
this is enuf. And for some apps, the need for / to be mounted is bad 
enuf - do not want to rely on any config deamon - much less a working 
network.

>> 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?

Thats a god question. But it don't get easier or harder by separatin it 
out in its own interface, do it? Rather, shuld every datatype be its own 
interface and optional? Realy no point in implementing a datatype in an 
backand that the underlaying config file can't store, and that the apps 
using that format dont ever use or understand!

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

Don't know if this need to be an interface. It's only an issu if the 
backend is a deamon (?), an then it can just refusing to do the action 
if the user don't have ther rights. Maybe ACL shuld be a datatype and 
ther shuld be a standard way to associate them with diferent keys and 
sets of keys. Then bakands can, or can not, provide that datatype.

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

Thats why I sugest a splitt in different interfaces. So, probably, 
atomic store shuld be its own interface to?

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

The API must specify this, ther will be some effort to adopt, but thers 
no way to get around that in any way?

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

I find it useful, but it might be an separate optional interface to.

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

Hard one, wher do ACAP find the default? Probably have to warry 
depending on backend?

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

Given the existing formats out ther, I think the API shuld suport keys 
being a directory, but that it might work or not depending on the 
backend. And a standard way to tell if it works for a given key 
(possably try and get a defined error).

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

Yes, I was thinking of 1). A config deamon have to find out what backend 
to use for different config (apach, postfix, etc). It can then figure 
out hove to activate changes to. Possably ther can be standard way to 
specy activation:

my.org/foo/bar/xdg_activate = sysv foobar reload

To say that any change under my.org/foo/bar/ is activated by:

/etc/init.d/foobar reload

or

my.org/foo/bar/xdg_activate = pid /var/run/foobar.pid 9

To say that it's activated by sending sig 9 to proces # in foobar.pid. 
OK, 9 is *not* a good chose ;-) but...

Some scary security consecvences thou, changing activation config shuld 
probably be hardwierd to require root privileges.

>> * 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?

Think the standard shuld say 'reasnoble time' but I will prefere 
implementations that try to do it ASAP :-)

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

To me, notifikatian is when someone *ask* to be notified of different 
events. If someone else ask (a config tool ask to notify postfix) then 
it's activation. My english is not to good (as You probably figured out 
by now), so pleas point out if my wordings are unclear.

Possably, a app can request to be notified in that way... but it's a 
strech. Think activation shuld be on demand, when someone *aske* for it, 
would not want the config deamon to restart apache every time I change a 
key in the apach config :-/

One more question. Shuld a config deamon lisen on filsystem events and 
notify liseners when I use emacs to alter config?

The simplest backend is to me somthing that parse a file, and then give 
an app a standard api to querry it's config - but only what that app 
needs. Att that level it make sens to use it in apps like postfix. 
Probably not to change postfix, but if ther is a god lightwegth 
implimantation ready, for writing new apps like postfix.

'sets' of config: host, group, user etc is somthing important to make 
standard. Some handy way to just get the 'right' value, acording to 
different overide roules would be nice, but might be best built on top 
of the API. This must be flexible - some app have only host config, some 
have host and user, but no group etc. It probably have to be expandable 
to. Thinking of bash with a sets of config depending on if its a login 
shell or not etc... but thats more of scripting and possably outside of 
any config systems scoope? The domain name *need* not be toplevel, this 
'set' part migt be toplevel, and left out if its not relevant for that 
domain.

Ther will be need for alot of werry specialised backends for different 
apps, but if the API take some momentum, appauthors might provide 
backends themself, to make ther app nicely integrate with many different 
config tools.

Classifikation of apps (server, desktop etc) is important to, but might 
not be best expressed in the key path. Some standard keys like the 
xdg-activate example above might do it better, and less interfear with 
existing solutions. This is much analogius to the menu standard discussion.

After all, the config GUI do not need to be analogius to the key paths. 
It can be app/service oriented and presented to the user in any way.

Shuld ther be an (optional) interfase for calling up the systems 
'standard' configuration tool on the apps config (asuming the app talks 
to the config deamon)?

/LaH