Re: New to the list- intro

["mark_harrison_uk2" <mph@xxxxxxxxxxxxxxx>]

--- In ukha_d@xxxxxxx, "Ian Lowe" <ian@w...> wrote:

> The distributed decision making you describe is very much xAP's
> philosophy (unless the BCS Mapper is a move to centralised decision
> making - Mark?) whilst smaller, more tightly regulated messages is
> ours...



Absolutely not.

BSC Mapper is a slightly odd product. On one level, it CAN be used as
a central control engine, albeit only for assigning connections in the
BSC schema.

On the other hand, it can be regarded as a central CONFIGURATION
engine, that will push out the configuration to the end-point devices,
and only send the necessary translation "live" if it has to.

Example - you configure C-Bus.light.blue to connect to
Homevision.input.1 in BSC Mapper

BSC Mapper then sends a xAP message that interrogates whether the
C-Bus controller supports distributed intelligence.

- If it does, then well and good. From that point onwards, the C-Bus
controller will change the blue light whenever a "Homevision input
port's changed" message is detected.

- If it doesn't, then no problem. From that point onwards, the BSC
Mapper controller will send a "C-Bus - change the blue light" xAP
message whenever a "Homevision input port's changed" message is
deteceted.

This makes it possible for developers to choose to support distributed
intelligence when they want to, but still be fully capable of xAP
control if they can't (albeit at the expense of NEEDING a central
controller at that point.)

Parsing the messages isn't hard - the limitation is on the RAM space
needed to hold complex configurations on very-low-powered devices. As
Patrick says, the reference PIC xAP code fits in 200 bytes of ROM.
Such a device is unlikely to have the capacity to hold a table of
"things I'm watching out for", and will probably just hold a
"this is
my addres - command me" configuration in 8 bytes.

Mark