hi all,
we (at least i) had a good time at the social at fire+ice tonight. i was
discussing a new module i am developing and i said i would send what i
have to the list. this is the most recent draft of the specs and there
are some open issues with the api and the design. so feel free to ask
questions, suggest features, solutions, whatever about this. i am
looking for outside eyes and branes as i have been working on this
mostly alone so far. if there is interest, we could have an open
discussion of it at the tech meeting next tuesday. in any case have fun
with this. if you want to help more or be a beta tester, contact me off
list. another goal i have with this is to give a talk about it at this
year's conferences.
uri
The class RulesEngine is designed to shepherd data through sets of logic
rules. These rules can process and modify the data as well as execute
side effects via external calls. Rules are Perl code references and they
are organized inside the engine in structures called
RulesEngine::Flows. Here are some of the primary features and benefits
of this module:
* Can handle and track multiple data objects inside the engine
* Data flow can be linear, or state to state or any combination
* Data flow has support for conditionals, loops and calls
* Can be driven from synchronous or asynchronous systems
* Less coding needed to create complex logic systems
* Easy to integrate in applications
* Rules and Flows can be loaded at runtime from multiple sources
(files, DB, network)
* A library of common Rules and Flows is provided. They can be
used or modified as needed
* Useful for network protocols, state machines, business logic.
Here are the primary Classes, their preliminary specs and some of their
methods. The API is still under development. Note that any names of the
form foo/bar are alternate names for that method. In your feedback
select the names you prefer.
All objects below will be constructed with key/value argument
lists. They can be passed as a hash ref or a list of pairs.
Class RulesEngine
This class is the core of the rules engine system. It contains all the
Data, Rule and Flow objects (see below) and manages the flow of data
through the engine. It is where all the external state of the Data
objects is maintained (of course, the Data objects maintain their own
data). Rules and Flows are inserted into the engine object and then data
objects are injected into it and targeted to a named Flow. The engine
manages which Flows and Rules get passed the Data based on the results
of the Rules.
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.
Timeouts are a critical feature for a rules engine/state machine so it
can be used in real time situations such as protocols. The module will
support multiple timeout techniques. unsupported timeout techniques can
be handled with the timeout_create method.
Methods and their arguments
RulesEngine class
new() constructs a new RulesEngine object
flows list of pairs of flow names and their rules.
or a list of flow object? more below.
flow_file file to load that has flows/rules.
multiple file/flow formats will be
eventually supported.
rules list of rules and their names. used to
installed rules that can be accessed by
name
timeout_style select from a support list of timeout
styles. these will include Event.pm,
Stem, SIGALARM, etc.
timeout_create this argument is a code ref to call when
the engine wants to create a
timeout. this call is passed the data
object (to be called back when the
timeout triggers), the timeout
period. the call returns a timeout
object which has a cancel method.
install_flows() install flows into the engine.
can be used on empty or running engine.
flows list of pairs of flow names and their rules.
or a list of flow objects? more below.
flow_file file to load that has flows/rules.
multiple file/flow formats will be
eventually supported.
