Re: Red Rat 3 / IR Schema

[patrick@xxxxxxxxxxxx]

>
> The sharing of the configuration database is really a general
problem in any distributed environment and this one simple case of
the IR database is a good candidate to based a discussion upon.  A
good solution for this one should able to be applied to other
situations where system-level information is needed.

[snip]

> In my other xap applications I implement a Config class.  It allows
a query mechanism by which a unit's configuration can be queried and
the full set of section/key/value triplets are communicated as a
notification.  It allows a push mechanism by which a central node
that contains this information can deliver it to each remote node.
The configuration information is stored locally at each node so that
during any new startup it will be able to use the last communicated
set of configuration information.
>
> This is the type of mechanism that I believe is appropriate for the
IR case that is being discussed.  The RR connector, when queried,
would deliver the full set of learned device/function names in its
database.

Perhaps this is a good point to re-open the whole "configuration"
can-
of-worms, since this is, as Michael points out, a particularly fancy
case of app config in part.

In keeping with the general xAP philosophy, I don't think there
should be a single configuration server. What I'd like to see is the
distribution of configuration data being managed as an extension of
hub functionality. A hub could choose to cache (and persist) messages
(which might use a new header type, xap-config-set), and then serve
up values to client applications on request (xap-config-get). The
system needs a little bit more policy layered on top to work
properly, but that's the basic concept.

Any thoughts? My proof-of-concept implementation seems to work well
(for me, anyway).

Patrick