spam at micropp.se
Thu Apr 29 16:10:12 EEST 2004
First, I'm not sure exactly *what* API we ar talking about her. But my
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
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
> 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
>> 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
my.org/foo/bar/xdg_activate = sysv foobar reload
To say that any change under my.org/foo/bar/ is activated by:
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
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
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
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)?
More information about the xdg