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