Re: IMPORTANT xAP Basic Status and Control

[Stuart Booth]

On Tue, 4 Nov 2003 02:38:53 -0000, "Kevin Hawkins"
<<a
href="/group/xAP_developer/post?postID=7mbucmPv-OUGWk56NRZ990PUkG5Eyu4WiFXQBxwWb88cJKmJqAnH7ajPZHiQnrG4DT_1vbGNkgB6CzlVX2xYQV8">lists@u...</a>>
wrote:

>Yes - or at least be able to select unused UID's somehow - there is no
>requirement for them to be consecutive I guess.

I put them in consecutive order as I think it's probably the best way
to increment them without any further instructions.

>Yes it does seem nice but it's not going to work for the basic device
>control as using such a UID will indicate it has endpoints that are
>addressable and have control/status.

Apologies if I've forgotten this from your spec (been busy lately) but
is basic status and control (BS&amp;C) mandatory for endpoint nodes?

Each of the 'plugins' in the container application is really a full
device in itself, so it could support BS&amp;C.

> > Thus I'd end up with something like this:
> >
> > Controller (FF122300)
> > +-- Device A (FF122400)
> >  +-- Sub 1 (FF122401)
> >  +-- Sub 2 (FF122402)
> > +-- Device B (FF122500)
> >
> > Is that right? Note that the main device has a 00 subaddress, and
each
> > 'sub' has its own subaddress value.
>
>Yes - I think that is best - and I do believe that starting your device
on a
>FFxxx0xx boundary is logically best - a sort of inference that the last
>digit of the centre part may be software subs as such.

Mmmmm, that's a neat little indicator, although it fails once the
tenth plugin is installed. It might be useful to easily be able to
determine types of application when forming hierarchies perhaps.

> Or possibly we could
>start such container apps with a UID of FFFFxxxx to reflect this status
-
>thoughts ??

So group all the container applications way up high in a reserved UID
space, and leave their inner components to customise themselves?

The container application, for me at least, is pretty well dumb.
Whilst it does forward on the messages to any of its plugins that want
to use that facility (there is nothing to stop them doing everything
themselves of course, with their own xAP message listener) other than
sending out its h/b it does naff all, so grouping them up high is
fine. However, I'd still possibly like to be able to determine which
software devices are grouped by that container. It's not essential,
just might fit in with an idea I've got kicking around in my head.

>This whole idea of container apps was not really anticipated when we
thought
>of the UID's but this seems the best way to accommodate it now. You do
get
>into awkward issues of how many of the apps should generate heartbeats
and
>if it is only the container then what happens should a component app
hang or
>disappear ?

Yes, this is what made my container project quite fun as it has to
manage all of this as far as possible. Here's a quick overview of how
I approached this:

1) The container application always sends out its own h/b.
2) Each plugin that is loaded can request h/b management if required,
and by default they pump out an individual h/b.
3) Each plugin has its own device name, distinct from the container
application.
4) If only the one plugin 'software device' is loaded then the
container application and the standalone plugin h/b are rolled into
one, using the plugin's device name.

So if one of the plugins dies, then its h/b just stops and the others
continue as far as they can.

S
--
Stuart Booth <<a
href="/group/xAP_developer/post?postID=XA6BC7JD0_we0T_kVPADVNG_HrkNYz43ArKg7Sx5C51UgNTfNnZqavNxWRxgaemSBCseSa2tN9sPtqWGnw94jg">stuart@x...</a>>
xAPFramework.net - a xAP software development framework for .net

<a href="http://www.xapautomation.org/";>http://www.xapautomation.org/</a>
<a href="http://www.xapframework.net/";>http://www.xapframework.net/</a>