RE: xPLHal scripting matches

[Kevin Hawkins]

> -----Original Message-----
> From: Tony Tofts [mailto:<a
href="/group/ukha_xpl/post?postID=iQuVUE3PUIlQLnPdF8mr6jJm6wzzp1Qfjwu5i78Xa-kFNyM7oqwW0mcWA1gPNIzJBgkKqWfw7Syf8Q">tony@x...</a>]
> Sent: 10 September 2003 20:40
> To: <a
href="/group/ukha_xpl/post?postID=D62_f2BNJIeDH-i3cDaY8WjjqEljkbTvs0rHBef9yX7d9shoGjA6Tsps8kaXvbLe_rikXyYM8XOkohvHNTWRBmFceg">ukha_xpl@xxxxxxx</a>
> Subject: RE: [ukha_xpl] xPLHal scripting matches
>
> > I think it would be better if the message came in, and all
> > matching subs were executed - and if it's sequential,
> > sys.break() could be used to tell xPLHal not to continue
> > processing beyond the current point.

This would suit me too

>
> This can be done, if they do run sequentially, but it means the
> constructs
> will need to very carefully done. There's a strong chance the _same_
> script
> could run multiple times, dependent on the users approach to building
> the
> consturcts?
>
> > Either way... it's quite a big change, and probably not
> > something we have the time to look into for a while :-(

So my current idea of looking for all osd.basic messages and routing them
out to a PC display application is not really workable in the current
implementation as it will interrupt any further processing. I think this is
going to be quite an important issue and will affect all class.type
filtering in xPLHal.

As the default is currently to cease further processing and it looks
like a solution may be a little way off, I will go back to plan (A) which
was to modify the Caller ID script to target the PC based screen display
directly. It's not as nice a solution as it uses the opposite methodology
to
the other scripting where displays are broadcast driven - it means that it
will only work for the callerID display too.

>
> Making it loop thru all matches is a minor change, but not sure how
the
> sys.break command could flag the thread?

[Just a thought - Is it not possible (as is current) to assume that
you will cease further processing (thus only launch one thread) but later
allow re-entering the xPL message back into the filter routine but starting
just after the line it left at such that it can progress down the list ?
This fork would usually be done (scripted) with the very last instruction
at
the end of the script effectively ceasing your thread but starting another,
(your thread would naturally die at it was at the end).
To implement the current (break) style this 'return index' could
perhaps be 0 or increased to a large value that forces it off the end of
the
XML list. If you wish to continue processing however you increment it by 1
and return it. The 'address' would initially be passed as a parameter
accompanying the xPL message to the subroutine call (this parameter would
be
an index to the line that matched). It needs incrementing or setting to 0 (
perhaps it could be auto incremented) defaulting to a sequential action.
This forces sequential processing however you could alternatively
presumably
issue the 'fork' earlier - at the start of your script thus permitting your
current thread to continue to run , and effectively spawning another
parallel thread later in the filter matches - this would offer the choice
of
having concurrency or sequential running. ] Or is this rubbish ??? :-)

K