On Mon, 2008-03-24 at 16:36 -0700, Joel Becker wrote:
> [Joel]
> Enough with the third person. I see no reason these API cannot
> coexist. In fact, they are just layers atop each other. While there is
> a question of who implements which layer, I think we've settled that a
> core library should present them so that we can drop extrinsic
> libraries like libcman (which is doing the API for Fabio right now).
> What does everyone think? Did I capture the ways we are seeing
> objdb access?
Note that Fabio's libcman/ccs API is effectively a subset of XPath[1] as
is used today by CMAN and friends to run down an XML tree. CCS was just
a daemon which wraps around XPath in a distributed fashion, which we can
do from libcman now.
I don't know the internals of the asynchronous API, but it looks pretty
cumbersome to use with a tree structured configuration if the structure
of the tree itself is dynamic.
With a sync API, you can build your queries as you go:
get_config_attributes_recursive(key, node) {
while(has_children(node)) {
child = get_next_child(key + "/child::*");
if (child) {
get_config_attributes_recursive(
key + "/" + child->name,
child);
}
}
if (node->type == "foo") {
get_foo_attributes(key, node, "foo");
} else if (node->type == "bar") {
get_bar_attributes(key, node, "bar");
} ...
}
In the case of rgmanager[2] (which currently uses CCS), this happens
frequently enough that it's interesting; admins can craft services in
any structure they want.
For example, a node might have its parent deleted, which would affect
how that node's values are interpreted, and what keys identify that
node's attributes/values:
foo{
name: temp
bar{
name: bar1
baz{
name: test
value1: one
value2: two
}
}
}
... might become:
foo{
name: temp
baz{
name: test
value1: one
value2: two
}
bar{
name: bar1
}
}
Baz went from being bar's child to being its sibling. However, no
values of baz have changed.
Currently, we key off one value in the configuration (which has a
statically-defined location in the configuration). When that value
changes (ex: delivered by an async callback[3]), we traverse the new
configuration tree in synchronous fashion, learning the new structure of
the configuration as we go.
-- Lon
[1] http://www.w3.org/TR/xpath
[2] Pacemaker will also run into this if it ends up using openais for
configuration data at some point, I suspect (currently it rolls its own
which is just XML)
[3] CCS doesn't have a callback, but we wish it did for this purpose :(
_______________________________________________
Openais mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/openais
