On Tue, Jun 26, 2001 at 09:35:39PM -0400, [EMAIL PROTECTED] wrote:
> 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.


to me this looks like a need for some more machine types. there are several
models out there, one certainly fits. NFA is useful for data driven
machines (events being input data), for example. There are some
programming languages that do this thoudh I don't remember the names.
What I want to say is that there are some pretty well researched things and
that the best would be to take a look and pick one. Easier than inventing
something new and might be proven to work as well.

the object interactions would only help as they're on a higher level and
easy / well-defined things should become easier.

transaction monitors would need something like the above as well (the
semaphores+dependencies, i think they're called barriers as well especially
in OS context).


torvald

Reply via email to