Valid for Rules 2.x
I'm thinking about inheriting RulesOptimizedRuleSet class from RulesPlugin class. That will implement its execution, insertion functions and other basic functions.
Other modules would provide their implementation of hook_rules_optimization_rule_set, which will in turn create a new instance of above mentioned class and add rules to the optimized rule set. We can store the pre-processed decision tree in cache as set_(name). So rules_invoke_rule_set() would invoke the execute() function of RulesOptimizedRuleSet. This will make both existing rule-sets and optimized rule-sets to work with the modules.
This is my basic idea about overall functioning. I'm looking forward for suggestions and comments.
Comments
Comment #1
fagohi.
I think we don't need necessarily a new plugin, as plugin configurations can be saved as valid configuration, which doesn't make much sense as it's just an optimized version. So I'm not sure whether we need a new plugin, might be feasible though. Anyway, first of we need to came up with a way to integrate the optimization regardless whether it makes use of a new plugin or not. I discussed that with klausi and I think the best way to proceed is:
1. RuleSets gets cached using the cache system before they are evalauted, we can step in there and optimize it. -> So we can the optimized rule set only, while in the db we still have the original one stored.
2. To do that, we need a $set->optimize() method which does the optimisation. For that make use of faces + hook_rules_plugin_info() - have a look at its doxygen docs. Define a new interface for the optimize method() + a default extender class which contains an empty method and it to the rule set plugins, such that one can call ->optimize() everytime. -> Roll a patch for rules2 for that.
3. In your module provide an extender which contains the acutal optmize() implementation... :)
Apart from that we need to make sure in Rules 2.x in general, that actions are evaluted after *all* conditions of a set. But that's a separate issue.
Comment #2
klausiAnother remark: We can do the optimization without problems on the Rules Events sets, where all conditions are independent from other actions that are executed. On the contrary, a ordinary rule set (RulesRuleSet) is often used to define some sort of workflow, where conditions may depend on the outcome of previous actions. I propose a background solution that does optimization only on independent rules, that do not interfere with each other.
The approach I discussed with fago:
1) Put a rule on top of the ordered rule set list
2) do an integrity check
2a) if the check fails: we know that this rule depends on another rule. Exclude this rule from the optimization set.
3) Select the next rule and go to 1), if all rules were examined go to 4)
4) Optimize the remaining set of rules (they do not depend on each other)