RE: xPLHal scripting matches

[Kevin Hawkins]

> -----Original Message-----
> From: Ian Lowe [mailto:<a
href="/group/ukha_xpl/post?postID=2ggY5V-qm4PNWFgmSimebQ1La9jpWRa2Ko404EYfgiYZ3XpkY-DHeX4bxmenjhHH4WRZzOQbbLVLi7mgtGM">ian@w...</a>]
> Sent: 12 September 2003 22:55
> To: <a
href="/group/ukha_xpl/post?postID=iRZO1CNz5zL6IDPLRpLCKW_i-_PzSkQwn6pnRKqP4XybF5hrw3T-ViuXTQqvQTmwpfu036t-NK_ajJwOpppoVQ">ukha_xpl@xxxxxxx</a>
> Subject: Re: [ukha_xpl] xPLHal scripting matches
>
> I think I have finally got my head around this problem, and have a
> suitably
> long response. ;)

I don't think we're 'in synch' here and therefore have an even longer
response.. :-)


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

Sorry Ian - I am not trying to be awkward here, and I am very conscious
that
I am a 'xAP' person on an xPL list but I still see it as a real problem -
However the workaround that we have - that Tony asked for comments on,
solves it very elegantly, and with fairly simple coding changes I hope -
without messing anything up at all... full backward compatability.

When I posted to the list on this issue I did so because I believed it was
not in any way a xAP related issue. It just so happens that what I was
doing
with the xAP gateway within xPLHal demonstrated the problem. I was trying
to
offer an 'on screen display' function for your CallerID example making use
of a xAP application that does this - allowing you to meet the criteria
that
Mark asked for and also trying to respond to your call to the xAP community
'to script some examples of the xAP gateway functionality.

>
> 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.

Exactly the same in xAP - no advantage or disadvantage

> 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.

All xPL messages are seen by ALL other xPL capable receivers - they have to
be because the nature of the udp send is broadcast - it goes to a broadcast
"X.X.255.255" or variant address. Even when you send a targeted
message it
is sent on a broadcast address. It is a much higher level of the protocol
that effectively throws the message away when it chooses to do nothing with
it. Every receiver has to make the conscious decision having already
received a message that is not targeted at itself to 'do nothing' - it
could
quite easily make the decision to do something with the message effectively
eavesdropping on the conversation. It is true that it could make an early
decision to cease ongoing receipt of the message once it realises it is not
one that it is going to need to hear. It is impossible to have a private
conversation in xPL. The same is true in xAP also, it offers no advantage
or disadvantage in this respect, it is designed into the protocol
deliberately and is a good thing as it enforces the boardroom analogy that
all devices can communicate with all others and non can talk privately.


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.

Again, you can't technically send it only to one receiver - what you can do
is ask all the other people who receive it to ignore it.

>
> 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.

The issue is when you want to match on classes sometime and addresses
another - that's the crux of the problem.

> 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.

One probably

> 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.*.*

It still doesn't help though

>
> If you can handle all of the messages coming from that device in
"one
> big
> script".

Well what you are saying is that I have to either check and script every
class.type within every source (and not use class filtering) or check and
script every source within every class (and not use source filtering) -
both
are absolutely unwieldy &amp; the wrong way of doing it.

> 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

These are fully qualified matches.. Now you have to have a filter for every
source that supports an osd.basic class ......including ones yet to be
developed. I don't think even xPL developers can do that ;-)

But the issue remains that having matched on a class.type no further
matching of any form - however wild *.*.*.* or defined as above can take
place - the search for a match has been abandoned.

>
> 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.

I still think we're seeing this from a different perspective - and if you
consider the problem of intercepting the osd.basic schema then you will see
that it just can't be done - unless you create a fully qualified match that
involves all the source address as well - and you do this for every
possible
device that could send osd.basic - including the ones that don't even exist
yet.

>
> 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.


The bottom line is that you can't match on just a class.type within the
current script mechanism without pre-empting later matching on addresses -
likewise if you put the addresses first you pre-empt the class.type
matching
later. It's because they can 'overlap' within one message but can exist
separately too.

Try it if you like - try and write a script that will intercept all
the osd.basic messages from anyone - and then try and also watch for a
device (that sends osd.basic schema messages) by it's address such that you
can catch all the classes it uses.

Kevin