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

[mcs101main@xxxxxxx]

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

I'm not wild about the apps that also masquerade as hubs for a couple
of reasons:
[snip]
I agree with Patrick that dual-role applications are problematic.  I really
prefer
applications that just do one thing because in the long run they are easier
to maintain, easier to diagnose, and easier to manage in realtime.
I also agree with Stuart that for startup-level implementations a built-in
hub is a great feature.


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.
[snip]

I understand the hub to be an artifact of an implementation restriction
and not really an intrinsic xap component.  I would not want to build
a specification upon something that came about only because of an
implemention restriction.
The hub provides a vital role in current implementations.  This does
represent a single point failure for xap applications that reside on the
same PC.  Because of this criticality it should be as simple as possible
and stable as possible.  It should not be evolving as the configuration
and startup functions are being integrated into it.


>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.
[snip]

A hub, by definition, is a singular application for which no other can
provide the service.  A configuration/startup function can be monitored
for proper operation and actions taken to place a backup for this function
into service.  Redundancy can be used to improve system up time.  The
system design needs to consider how to manage redundant functions.
Since a hub cannot be redundant then it cannot be managed when it fails.



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.
[snip]

totally agree


> 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.
[snip]

All I was trying to convey is that we now have a special class for
a heartbeat that implements the exception that a body is not required.
My thinking is that I do not want another class that has special-case
behaviors.  Yes, a class needs to be defined to facilitate the system-wide
awareness of the configuration, but this class should be have and any
other.



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.
[snip]

Please elaborate.  Is there another layer of the xap Framework beyond
messaging?
-------------- Original message from patrick@xxxxxxx: -------------- --- 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]