[rules-dev] time behaviour, suggested changes

[Mark Proctor]

Currenty timer initialisation is not defined very well and rules don't 
obey salience, which can make them harder to use.

Agenda interaction and scheduling:
1) Rule activations are added to the agenda like any other rule.
2) When the rule is popped from the agenda, instead executing the RHS 
the timir started is started.
3) Each time the timer is triggered the rule is added to the agenda and 
continues to obey salience. This time when the rule is popped from the 
agenda it executes the consequence.

Fact modification behaviour:
Modify on scheduled rules currently retriggers the initial delay, if 
that's 0 it can cause the rule to refire straight away, which I believe 
never wanted.
1) If the timer expression does not used any modified fields, it should 
not be re-scheduled.
2) Reschedule should be done for the repeat period only, we shoud not 
trigger another delay.
3) The first time it is scheduled after the period has changed it should 
subtract the amount for time difference left over from the last period.

For those that want timer rules to fire independant of the agenda, we 
will probably add an annotation to specify the rule is not to be handled 
via the agenda. This will give behaviour roughly to what we have now.

One reason why this change is important is with the upcoming algorithm 
change for lazy rete. We need to use the agenda and rule priorities to 
determine when to evaluate rules. Any rules not handled by the agenda 
will have to be left eager, so there are significant performance gains 
from this, as well as userbility gains from having timer rules that 
still obey salience.

Mark