On Jan 19, 2005, at 10:42p, Uri Guttman wrote:
Question: should there be only a singleton RulesEngine or should it
allow multiple instances? you can always emulate multiple state machines
inside a single one with proper namespace management. In any case, the
class must track all created engines so it can map data objects to their
owning engine objects.
It doesn't appear that there really needs to be only one RulesEngine. Also, consider mod_perl, where multiple applications would like their own engine. I vote no singleton.
IDEA: is this argument hash read only? can it be changed as a
whole after the flow starts? if the outside code keeps access to
this hash, it can be changed by outside code. this can be used to easily change runtime behavior on the fly.
Modify the flow on the fly? Sure!
> the second argument is the flow's argument hash (see above).
this hash ref will have the data attached to this flow
instance. it will be used for default values, or data that won't
change often, or flow logic changes.
Arg, I'm lost. Why not just pass it the ::Flow object?
rules return either a token or a hash ref or an empty return
(not return undef!). the return value is used by the engine to
determine what to do with the current data object. a single
token can be used if the return is simple or a hash ref of
tokens and values can be returned.
This seems to warrant creation of RulesEngine::ReturnValue or something.
my $rval = $flow->(....);
# use $rval->next_rule, $rval->wait, $rval->buffer, ... we can enable a data object tracing via a method. then each time
a rule is called with this data, a trace log is appended
to. this will probably need to be inside the data object but see
above for the design issues).
Log4Perl sounds ideal. (?)
Transactions
Nice!
...the Expect.pm module can do) is it can manage multiple flows through the
state machine at the same time. so this module is perfect for event loop
systems and other parallel applications.
Care to write some examples? I mean, they don't have to work, but for something like an SMTP client for example.
-- Ian Langworth Project Guerrilla Northeastern University College of Computer and Information Science
_______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
