RE: xPLHal scripting matches

[Kevin Hawkins]

> -----Original Message-----
> From: Tony Tofts
> Sent: 12 September 2003 16:57
> Subject: RE: [ukha_xpl] xPLHal scripting matches
>
> > > I had no plans to include bridging to xap.
> >
> > I don't think that the xAP inclusion has caused this - my
> > usage in this context may have been the first time it became
> > evident though ...
>
> I'm not blaming xap...
>
> I just can't forsee, except in very weird circumstances, where a pure
> xpl
> (as it was originally intended) system would have a need for this. If
> someone wanted to process all CID messages, this can just as easily be
> done
> with the existing system.
>
> E.g. if you wanted to capture all CID messages (and don't want to
write
> a
> device/app specfic script) then you can just set a filter up
> wildcarding
> everything except the schema class, which would be cid.
>
> schema msgtype="*" source_vendor="*"
source_device="*"
> source_instance="*"
> schema_class="CID" schema_type="*"
subs="CT" />

I think I am still missing something here because as I understand it if you
included the above line and also wanted to include say the following filter
later in the XML file

> schema msgtype="*" source_vendor="*"
source_device="CBus"
> source_instance="*"
> schema_class="*" schema_type="*"
subs="CT" />

Then for a device sending...

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

CID and CBus are bad examples but X10 and CBus is a better example when you
might have a hybrid implementation and need to trap all X10 and all C-Bus
messages (one trapped on class and one on device).

Ignoring xAP totally - my silly little example of wanting to trap all
displayed messages is something that someone might want to script for a log
application or something. Or another example they may well want to trap all
CID messages for example and log where the number is '01234567890' for
example.. but they just want to intercept and not break the filters.


>
> > action=continue or action=break
>
> Were trying to avoid modifying anything that would break an existing
> install
> though.

I think you missed the next line in my original message which you
<snipped>
it reads...

Kevin Hawkins said...
>In this way each filter has the option to ask the matching to continue
-
>and if you assume a default of 'break' if this parameter is missing
then
>all existing systems will be unaffected ...

Maybe it wasn't clear what I was trying to convey here but what I
meant is that if the 'action' parameter is absent in the XML file then you
default it to 'break' which is exactly what happens currently... every
current script would continue to run unmodified wouldn't it ???

>
> I pretty much consider xplhal (and xpl) to be 'in production' so to
> speak.
> The core is complete, were just adding improved/extra functionality
> (e.g.
> script reload recovery, xap support) and sorting any odd undocumented
> features (bugs?). Ideally this needs to be able to be dropped into any
> existing install without disrupting it, if possible.

I think my proposal achieves this - whereas the other option would cause a
change in script actions and/or would require changes to the XML file.
Which
is exactly what you're trying to avoid isn't it ??



Kevin