The idea of POE scripting has been floating around for some time now.
Here are some other ideas on it.
A POE script is a series of states that are triggered in succession, but
share some amount of data. A simple script would be :
get_sequence, validate, create_dir, mail_buyer, mail_merchant,
send_response
ARG0 is shared between all events, so it acts like HEAP, but across
sessions.
Now, some of these states don't have to be in a specific order :
get_sequence, validate, [create_dir, mail_buyer, mail_merchant],
send_response.
With [] denoting concurrent states.
Another way of looking at this is to have semaphores between each state.
() get_sequence (A)
(A) validate (B)
(B) create_dir (C)
(B) mail_buyer (C)
(B) mail_merchant (C)
(3C) send_response ()
This means that validate waits for get_sequence to release A, that
create_dir, mail_buyer and mail_merchant wait for validate to release B
and that send_response waits for the previous 3 to release C.
Or lets put it another way : states have "prerequisites". An event can be
enqueue at any time, but is fired when the prerequisite becomes true.
This would also allow branching, looping and much more.
For implementing, I don't think that pre_invoke hooks will work for this,
because while it can prevent. At first glance, macro
dispatch_one_from_fifo would have to be modified (eek!) Maybe we should
borrow a page from memoize and put wrappers around the subroutines... but
this wouldn't work with inline states.
Stem has something long these lines, by implementing a mini-language. I
don't like this approche.
This would be another use of Torvald's object interactions. In TPC4.0
proceedings, Kevin Lenzo has a paper about the Geckobot that explains how
internally it uses relationships. (BTW, the paper is worth reading for
it's ideas about messages and passing thereof.) Also, Data::Flow does
something similar.
-Philip
