Re: xPLHal scripting matches

[Ian Lowe]

>From: "Kevin Hawkins" <<a
href="/group/ukha_xpl/post?postID=fluS2y4HYW7f0KoQEFj3OJuwcYaMrp_2v_z90z4VJHkZZ1dCX-mhr5_5QBlmt3cZSRGRDxP_BzDj2gOH1XY">lists@u...</a>>

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

We have to get past this. My last post was not in any way intended as a
"mines is better than yours is, nar nee nar". It's trying to give
some
background to *why* it's built the way it is, that's all. Now If I use the
words "suck" and "rock" ... ;)

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

Any receiver built using the frameworks has this decision made for them.
There's an explicit flag "pass nomatch" which defaults to
*false*, causing
this behaviour. The actual developer written code processing the message
doesn't see messages at all unless they are "target=*" or
"target=me",
unless they have a *specific* reason for doing so.

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

see above.
The decision to promiscuously listen has to be conciously made by the
developer at build time, and the "out of the box" default is not
to.

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

I understand that, yes.

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

Well, that is what I am saying, but I think you are overstating the burden
involved!

There are a limited number of devices on a xAP/xPL network, and each of the
devices produces only a limited number of message schemas. Even the richest
device we have looked at so far (Homevision) can use OSD, TEMP, CONTROL,
X10
and IR

Possibly more, but that's about it.

You have one HV on a network, so, in practical terms you would only need to
have one sub, handling five or six schemas, *or* five or six much smaller
subs matching the device + osd, device + x10 and so on.

> 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 ;-)

er no. fundamental idea: the greatest intelligence on the network is the
fleshpod sitting in front of the keyboard. We don't need to script for what
doesn't exist. we don't even need to script for what exists, but isn't
installed on this network.

If I add a new device or app, after It's configged, the next thing I do is
think "how will this interact in my home environment, what do I want
it to
do?" then you write a script to handle the messages your new toy will
generate, or you modify older scripts that now need to know about it.

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

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

And doesn't *need* to be done. I see logging (as per the OSD example) as
pretty much the only position where you would want to catch every message
of
a given class. I'm not seeing any others, but if there are, I'm sure the
same solution applies:

Logging is not a script engine operation, it's an application in it's own
right. The best way to log xPL messages is to write a monitor app (one of
the specific reasons for turning on "pass nomatch") that fires
all of the
messages into a database, where you can filter by schema, whatever.

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

You don't have to write code to handle everything that is, or will be: only
what's actually here!!

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

I accept that completely: I understand what you are saying and I can see
the
restrictions that it puts in place. I just don't see the need to change it,
possibly introduce other issues, and result in a much more complex system,
when at the end of the day, there seems (to me at any rate) to be even more
possibility of weird behaviour: the likelihood of having overlapping subs
firing off that interact oddly etc..

and now.. I'm off out to Build a shed :)

Ian.