Dave Cridland [Home]
dave at cridland.net
Thu Apr 29 14:04:13 EEST 2004
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
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
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
> * 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.
More information about the xdg