Re: xPLHal scripting matches

[Ian Lowe]

I think I have finally got my head around this problem, and have a suitably
long response. ;)

Or rather, I now see what the *perceived* problem is.

There are two distinct methods of addressing within an xPL message
environment: You can address a message to a specific device through the
"target=" header element, or you can send a broadcast
"target=*" message.
It's worth noting that the development frameworks explicitly enforce this
behaviour:

If I send a message targetted to the mixer on my pc, it looks like this:

xpl-cmnd
{
hop=1
source=WMUTE-MUTETOOL.kepler
target=WMUTE-SNDVOL32.KEPLER
}
control.basic
{
zone=master
command=off
}

This message is not even *seen* by the X10 controller running over on
TURING, by design. If I send an X10 message, I get this:

xpl-cmnd
{
hop=1
source=WMUTE-SENDER.CMDLINE
target=*
}
X10.BASIC
{
COMMAND=ON
DEVICE=F5
}

It goes everywhere, and any app can act on it, again by design: I could
just
as easily send the message *only* to the CM12 sender. That's it: you pays
your money, and takes your choice.

What we have here is a similar thing (I think)

You can match on a device, or any part thereof, and you can match on a
schema. You just aren't supposed to match on really broad selections. When
we were designing the filtering mechanism, it was seen as being a very
powerful thing, but ultimately something that required the automator to be
more selective to use properly.

In this example:

> ...
> Source=UKUSA-CBus.kevin
> ...
> }
> CID.display
> {
> whatever
> }
>
> could never be picked up by my second filter because the first filter
will
> have trapped it. So I couldn't set up filters within xPLHal to
intercept
all
> class=CID messages and all device=CBus messages - neatly. I agree I
could
> add a test within the the CID trap to see if it was a CBus message and
take
> appropriate action but that is highly unstructured.

The problem vaporises. it's essentially only a problem because the matching
criteria are too open. How many CBus gateways will there be on a network?
I'd guess one, perhaps two. Instead of the really wide match of

*.*.CBUS.*.*.*

you should have a sub matching on XPLCMND.UKUSA.CBUS.KEVIN.*.*
and one matching on XAP.UKUSA.CBUS.KEVIN.*.*

If you can handle all of the messages coming from that device in "one
big
script". If you found that handling each schema a device can produce
was too
much hassle, then you use deeper matching, like

XPLCMND.UKUSA.CBUS.KEVIN.OSD.BASIC
XPLCMND.UKUSA.CBUS.KEVIN.CID.*
XPLCMND.UKUSA.CBUS.KEVIN.CONTROL.BASIC

Ensuring that there's a match for each one. Pretty much the same situation
exists when matching against the Schema being used: if you want to match on
a schema, you need to handle all of those messages in your code. if you
don't want to code for all of those options in "one big script",
you break
the problem up by being more specific.

Simple version: if you cast a wide net, you write bigger scripts. if you
cast a narrow net, you write smaller scripts, but more of them.

Ian.