Re: Event loop with rules handling

A few questions:

How will your program be notified (or detect) the external events?
When an external event is notified, do you antisipate iterating through all your rules in order to decide what to execute?
Alternatively, do you want the external event to cause only those rules that might cause some actions to be executed, to be evaluated?
Where will your program pick up the value of the variables used within the conditions, from?
How (and in what form) would your program pick up the rules?
- Read them in from a file at startup?
- Update them dynamically?
- Import them as Perl code?
- Parse as non-Perl expressions and interpret them at runtime?

There really isn't enough information in your post to base suggestions on. Things that come to mind are:

triggers set on columns in a DB, that invoke stored procedures when values are added or updated.
Something like a tied hash.
When the main loop (or thread) monitoring the external events updates one of the keys in the hash, the tie implementation processes a set of rules and associated actions for that key.

Several other ideas are alluded to in my questions above, but there's little point in expanding them on the basis of what you've told us so far.

Examine what is said, not who speaks.

"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
"Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon

Comment on Re: Event loop with rules handling

Replies are listed 'Best First'.
Re^2: Event loop with rules handling by Brovnik (Hermit) on Nov 04, 2004 at 12:39 UTC
All good questions. I'm early enough in the cycle that I haven't made the decision on a lot of this stuff yet, but, here goes : External events will prob. be either via signals for occasional triggers, or using sockets for regular changes. Whether to iterate over all rules is really a performance issue. One option is a register of variable that would change per rule, so on a change, only those affected would need to be evaluated. I expect the eval loop to be so quick though that this won't be needed initially Picking up rules - There would be a set of startup rules. Some would need to be created dynamically. My ideal would be to parse non-Perl expressions and interpret them. Triggers on DB columns - I considered this, but don't want the business logic encoded in the DB. What would be ideal is for e.g. a new/changed row in a DB to trigger an external event to prompt the Watcher to reevaluate. The DB will be MySQL, not sure if this would be possible with callbacks. May need some homework. -- Brovnik	[reply]

Replies are listed 'Best First'.

Re^2: Event loop with rules handling
by Brovnik (Hermit) on Nov 04, 2004 at 12:39 UTC

External events will prob. be either via signals for occasional triggers, or using sockets for regular changes.
Whether to iterate over all rules is really a performance issue. One option is a register of variable that would change per rule, so on a change, only those affected would need to be evaluated. I expect the eval loop to be so quick though that this won't be needed initially
Picking up rules - There would be a set of startup rules. Some would need to be created dynamically. My ideal would be to parse non-Perl expressions and interpret them.
Triggers on DB columns - I considered this, but don't want the business logic encoded in the DB. What would be ideal is for e.g. a new/changed row in a DB to trigger an external event to prompt the Watcher to reevaluate. The DB will be MySQL, not sure if this would be possible with callbacks. May need some homework.

--
Brovnik

[reply]