>>>>> "IL" == Ian Langworth <[EMAIL PROTECTED]> writes:
IL> 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.
IL> It doesn't appear that there really needs to be only one RulesEngine.
IL> Also, consider mod_perl, where multiple applications would like their
IL> own engine. I vote no singleton.
i have already gone in that direction. multiple engine objects is the
choice.
>> 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.
IL> Modify the flow on the fly? Sure!
that is one reason this is not just a different state machine. it is
meant to be very dynamic. even loading new rules and flows will be
possible at runtime. classic state machines are usually static.
>> 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.
IL> Arg, I'm lost. Why not just pass it the ::Flow object?
i have been thinking about this and since individual rules can be passed
args i am not sure of the need for this flow specific hash. those two
concepts seem to overlap and i like the args per rule way better.
>> 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.
IL> This seems to warrant creation of RulesEngine::ReturnValue or
IL> something.
nah, i want to keep the objects to a minimum. the return value has no
methods or logic. it is just the return status/action of this rule.
IL> my $rval = $flow->(....);
IL> # 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).
IL> Log4Perl sounds ideal. (?)
possibly. or a hook to use whatever logging system. if this module is
used in stem i would want it to use stem::log. a hook/callout is easy
and you can write a sub to work with any logger. this module will not
hardwire any other specific modules in it. timers will also be handled
by callouts so it can support different timer technologies.
>> Transactions
IL> Nice!
this needs much more work as it is only a basic idea. it might be a
feature for a later version but i want to make sure the idea is on the
table so it can be easily added later.
>> ...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.
IL> Care to write some examples? I mean, they don't have to work, but for
IL> something like an SMTP client for example.
i am still working on the api so it is hard to come up with concrete
examples. i would like to have a discussion of the api at this tech
meeting. i exchanged some email on this with damian and he helped
clarify many ideas and i like what i have now. i need to edit the api
doc to reflect it. some of the ideas are that the data hash is just a
plain unblessed hash. all methods are just called on the engine object
and the data hash is passed as the key arg. we also discussed different
ways of how rules get args and that is in flux. one idea is to drop the
flow args thing as each rule in a flow can have its own args so that is
redundant. this means one less thing to pass to a rule. so a rule could
be called like this:
sub rule {
my( $self, $data, @args ) = @_
$self is the engine, $data is the data hash and @args are the args
passed to the rule in the flow structure.
flows are also just structures since there is no need to have methods on
them. this makes the entire engine have only one class (RulesEngine) and
it cleans up the api a great deal IMO. so you create an engine, install
rules (named from the core lib of rules or fully qualified code refs)
and create flows (in text) and load them (they get compiled to the
internal structure), and then inject data hashes into the engine. an
important key is that flows are text and not perl code so they can be
loaded from files, DB, over the net, etc.
i will try to get an updated api out before the meeting so we can
discuss it more and maybe i can doodle some examples.
also i am basing much of the flow stuff on the work i did on
stem::cell::flow. i will post some of the examples of that which will be
similar to what rulesengine will use.
uri
--
Uri Guttman ------ [EMAIL PROTECTED] -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
_______________________________________________
Boston-pm mailing list
[email protected]
http://mail.pm.org/mailman/listinfo/boston-pm
