The UK Home Automation Archive

Archive Home
Group Home
Search Archive


Advanced Search

The UKHA-ARCHIVE IS CEASING OPERATIONS 31 DEC 2024


[Message Prev][Message Next][Thread Prev][Thread Next][Message Index][Thread Index]

Config (was Re: Red Rat 3 / IR Schema)


  • Subject: Config (was Re: Red Rat 3 / IR Schema)
  • From: patrick@xxxxxxxxxxxx
  • Date: Tue, 15 Jun 2004 07:24:01 -0000

--- In xAP_developer@xxxxxxx, mcs101main@a... wrote:
> 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.

I'm not wild about the apps that also masquerade as hubs for a couple
of reasons:

- it could lead to weird, hard to diagnose issues if a particular app
has an out of date or defective hub. Whether or not the end user sees
issues then depends on the order in which he started the
applications. Urgh.

- currently it is not mandated for an app to include hub
functionality (and doing so would lead to unnecessary bloat), so an
end-user can't be certain that a hub has been started on a host
without resorting to RTFM.

An alternative point of view is that the hub provides a "xAP
infrastructure service" which includes a hub, and also configuration,
and possibly even starts/stops/download/install xAP applications on
that host depending on the configuration. [Yes, I realise there are
security issues that have to be addressed with this arrangement]. I
like this approach because it moves towards the point that the end
user doesn't really have to be consciously aware of the fact that
they are running a distributed system, and the control can be
ultimately pulled together into a single point of reference.

>
> 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.

I'm not sure I've fully understood this. My view is that there must
be a universal mechanism for setting and retrieving application
configuration in terms of the xAP messages that are exchanged to
achieve configuration. The payload of the configuration messages
(what is configured) will, of course, be application specific. There
implementation of the configuration engine is a free-for-all, so long
as it complies with the configuration messaging standard.

>
> 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.

Agreed.

> 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.

This is pretty much implicit in any xAP based configuration
mechanism, provided that there is a messaging standard for
configuration. Replication is simply a matter of (a) discovering the
current configurations at startup and (b) listening for updates to
component configurations on an ongoing basis.

> 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.

If you don't use a dedicated header, you run into difficulties with
apps identifying whether or not a particular message is a
configuration message. It either means that, as an application, you
have to know the source address of a configuration component
(undersirable, this is itself config info); or that the config
component has to know the target address of an application
(undesirable, the application may not have a configured address yet);
or we have to reserve/mangle a special set of class names (e.g.
config....) - also undesirable because it introduces yet another
addressing mode, makes replicating of config data more complex, and
most importantly, it increases the work each client application has
to do (they now have to filter every message not only by source and
target but also by class). Much cleaner IMO to allow apps to filter
on a single, fixed header, and provide a consistent config mechanism
across all apps.

Whatever the final mechanism is, the details will be pretty much
hidden from the application writer, since they will be exposed as
a set of API calls to the underlying xAP framework.


Patrick

[I'm not sure that mail client you use, Michael, but Yahoo seems to
struggle with quoting it properly]





xAP_Development Main Index | xAP_Development Thread Index | xAP_Development Home | Archives Home

Comments to the Webmaster are always welcomed, please use this contact form . Note that as this site is a mailing list archive, the Webmaster has no control over the contents of the messages. Comments about message content should be directed to the relevant mailing list.