RE: xPLHal scripting matches

[Kevin Hawkins]

> -----Original Message-----
> From: Ian Lowe [mailto:<a
href="/group/ukha_xpl/post?postID=y3U27lVJlq6zvr5YJ4bIa8z37FQLwphb9kzXsqJDx6SoKVC_AXdbmcQmvbUcYfHeOshiYWCJb95FkqbAcok">ian@w...</a>]
> Sent: 11 September 2003 09:55
> To: <a
href="/group/ukha_xpl/post?postID=aV2r3ljBfJbeZlv3-5QDxttIu-Q_nzsInYymSXMK095DM1WR_p5X4fB3qIEs4mhUEPQS0zr-KI4M5KKYKyhvBu0">ukha_xpl@xxxxxxx</a>
> Subject: Re: [ukha_xpl] xPLHal scripting matches
>
> > Comments?
> >
> > Regards
> > Tony
>
> The simplest seems best to me:

And me...

>
> I'm used to firewall thinking, where you match one rule and drop, so
> for me,
> it's easier to be clever with the rules, but I can see the limitation
> now.

Isn't a firewall methodology based around listing things NOT to pass rather
than things that can pass though ??

> (although, I don't see that it stops anything from working, you just
> have to
> think in a different way about things)

I don't think in the current setup I can trap all osd.basic messages can I
?? Without interrupting the filtering. I could check in every sub if it was
osd.basic I guess but that is definitely the wrong approach !
>
> however, I suppose it's more flexible to run all scripts that match,
> and
> build intelligence to "not run for this device" and so on
into the
> scripts
> themselves.

I think so but it does mean you have to add 'don't run this script' test
back into some threads - which is slightly untidy. This would be a runtime
coded thing though rather than being semaphore based if threads are running
concurrently. Obviously a continue / break is the neatest but I understand
why it is not achievable.

>
> I'm not sure that I can see why a script could run multiple times, but
> if
> Tony says it could, that's good enough for me :)

I'll assume this too - I didn't understand why either but I'll take it as
read

>
> Adding these two elements to the engine would provide a great degree
of
> flexibility: signalling and message passing between threads would, I
> think,
> simply cause much more complexity and speed issues:

It wasn't really message passing - just a return address pointer - in fact
maybe it could be automatic and you just 0 the value to stop further
processing - but it did create one more thing to consider and it did
naturally move the execution to sequential rather than concurrent. It was
definitely more complex.

>
> At present, x10 control via xPLHal and the CM12 is orders of magnitude
> faster than Homeseer was: I'd hate to lose that when, for all intents
> and
> purposes, the script engine in it's current form isn't limiting me at
> all!

Don't know about orders (plural) but it is very much faster, inevitably
anything X10 introduces at least a 1 sec plus delay - but that's X10. I
wouldn't want to see any changes that made xAPHal less responsive - it is a
great quality.

K