Re: Re: Red Rat 3 / IR Schema

[mcs101main@xxxxxxx]

--NextPart_Webmail_9m3u9jl4l_21172_1087248806_0
Content-Type: text/plain
Content-Transfer-Encoding: 8bit

I agree with Patrick that a single configuration server should not be the
singular solution.  I also feel that a hub is a hub is a hub and is nothing
but a hub.  There are several xap applications that provide hub
functionality because of the limitations of multiple xap applications on
the same PC.  It would not be right to burden them with configuration
management.

As my xap applications have evolved I have tended to use the GUI/Web
Interface provided by Homeseer as the user console to edit configuration
information and then use the Config schema in either a push or pull mode to
distribute it over the network.  Sometimes the Homeseer node does a query
of another xap node when it believe the remote information is the best
source.  At other times the orientation is just the opposite and the
Homeseer database is used as the master when queried by the remote node. 
While this is one approach to get visibility on a distributed configuration
it should not be imposed on anyone else's environment.  It should just be
viewed an another application on the network and not required by the
network protocol.

I think that there is sufficient variety of needs that xap should not
dictate how a configuration is maintained, but provide a mechanism by which
nodes can synchronize  information. This needs to consider redundancy
within the network so single point failures are not designed in.

It is quite viable to have an xap application that provides the function of
managing configuration information.  This app could provide a hub function,
if desired, as other xap apps double as a hubs.  There should be no
restrictions on running multiple config apps on the same processor or on
multiple processors.  There should also be no restriction that dictates
that a config app needs to maintain 100% of config information that passes
over the network.  Different classes of configuration data need to be
synchronized and this should be able to be done between two nodes that have
interest or with a configuration node that acts as a repository and
repeater of this information.

I have not thought too much about it, but I don't see the advantange of
extending the header types to implement a special one for configuraiton
information.  I see configuration as an application function within the
network rather than a supervisory one on top of the network.
-------------- Original message from patrick@xxxxxxx: -------------- >
> 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