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]

RE: xAP directory service/config/watchdog


  • Subject: RE: xAP directory service/config/watchdog
  • From: "Patrick Lidstone \(Personal E-mail\)" <patrick@xxxxxxxxxxxx>
  • Date: Thu, 28 Apr 2005 07:46:42 +0100



> It seemed there were 2 ways for config to work. An online or
> downloadable database containing all configuration items for each app
> and for each revision of each app and that db to be used againts
> configuration values received over xAP from the device.The other way
> was for all data to come from the device. The first method had the
> advantage of alot less xAP packets and the possibility of richer
> config options but has alot more administration in getting the db
> done. The second method was simpler but much more limited.

I see a hybrid solution as optimal, with the directory service acting as a
kind of cache for device config requests.

> The other
> two config issues hit were dealing with apps with no UID set and no
> name, this was partly got around by using a uid of FF000000 and
> assuming some random element could be put in the source ( mac
> address,ip, pc name etc). The remaining issue was the big issue,  sub
> devices. Configuring the master device was easy enough, subs caused
> issues. You could make each sub a configuable item just like the
> master but then you could endup configuring 255 items. So you would
> need a mechanism to groups similar sub devices and configure groups as
> a whole.  So now it get to the point, for config to work there needs
> to be a heirarchy within a device with devices/sub devices inheriting
> from above, in exactly the way ldap/active directory does. For it to
> work in a proper xAP sense there can't be a central app so however it
> works there will need to be replication of data between multiple
> config server and then it all get far too complicated!

LDAP generally does the replication for free. Key is the idea that only one
directory is the "master" (writable) at anyone time. The copies
are all read
only. Failover is managed by listening to heartbeats, with the highest
priority going to e.g. the highest UID.

How wide spread is the sub-address problem in practice? Is it really going
to be that common an occurrence that every sub-address needs explicit,
individual configuration? The only example I can think of is X10, where
each
device needs to be provided with a "friendly name" such as
"lounge lamp".

>I'll dig out
> the doc that was made as it would be good to get this config
> issue solved.
>
> On the watchdog/audit/monitoring app, one thing that will make it hard
> to really monitor things is that once xAP data goes through a hub you
> lose mac address and ip address information.Without these you could
> easily miss issues when multiple apps are running on identical
> defaults.  Stuart, is there any way of xFx passing this info
> on somehow?

Or fix this as part of the start up process? When an app starts it
identifies itself to the directory server as best it can as it requests its
config data. The unique key data is platform specific (e.g. mac address),
but contains a sufficiently random element (e.g. process start time in
local
clock ticks) that multiple instances can be correctly discovered. Where
multiple instances are legitimately installed on the same device, they can
be distinguished by install time ("first instance" was installed
first,
etc). This is enough to be able to deliver a UID from the directory service
on a fool proof basis. It only falls apart in the case where you have a
device which supports multiple instances of xAP applications, but has no
non-volatile storage of its own - and I think we can live with that
limitation?

Patrick





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.