Bug 4778

In response to comment 2 of bug 4776, one would prioritize rules across classes
by doing multiple calls into the rule class plugins, most likely one call per
priority.

Meta rules can track their own dependencies, so there is really no need for meta
rules to themselves track priorities.  Each call into the meta rule type plugin
would evaluate those rules whose dependencies have been met.

Created attachment 3356 [details]
nonfunctional concept code

This is a not-yet-working stab at moving the "body" rule type into a plugin.

do_body_tests() has not yet been moved into the plugin.  I also need to figure
out a generic way to deal with user_rules_to_compile, head_only_points,
body_only_points, and a few other loose ends.

Basically, the idea is that rule type plugins are responsible for:

* Registering their tests with define_test
* Storing their own test definitions
* Obtaining any data needed to evaluate their tests
* Evaluating their tests when called through check_priority

Rule type plugins may ignore priority when appropriate.  For example, the meta
type plugin may evaluate a test when all its dependencies are met and DNS type
plugins may evaluate a test when all its DNS responses arrive.

There is no eval type plugin, but there is a core eval test subsystem that can
be used by rule type plugins.

Please DO NOT forget about allow-user-rules.  Done properly it should be 
possible to preserve the base rule set and create multiple overlays (much like 
C++ subclasses) that can be activated when the particular user runs.  If the 
particular user has no rules of his own, the base rules can be used without 
modification, other than possibly the score values.

One might ideally want to consider being able to compile individual user's 
rules once on the first time they process a mail, and then cache and retrieve 
the precompiled rules for subsequent mails, unless the rules change in the 
intervening time.  If not thought through from the start this can get into the 
sort of mess that has now and then shown up with caching various user option 
configurations, and having one pollute another.

I see no inherent reason that allowing user rules should result in recompiling 
the entire ruleset on every email processed.

In response to Comment #1, it might be good if calling into a plugin to 
evaluate one or more rules at priority N returned the next lower priority at 
which there was a runnable rule.  This could help the rule driver make 
intellegent calls into the various plugins.

noting cross-bug dependency

btw, this would be an ideal way to allow people to work on alternative
"backends" for rule types, too; for example, code which used the trie-optimized
regexp interpreter new in perl 5.9.2, could use an alternative backend for the
"body" rule type.

I really quite like this idea.  Is anyone working on it these days?

Created attachment 3575 [details]
Updated work in progress

Here is what I have so far.  I haven't worked on it for a while.

The next problem to solve is the RepaceTags plugin, which currently reaches in
and mucks with the internal representation of the current implementaion of rule
types.	I believe the rule type plugins which use regexes need to call_plugins
to a newly defined hook which will allow ReplaceTags to modify the regex.

I'd like to get my dispute with Michael Parker resolved before doing any more
work in this area.  Perhaps a design meeting at CEAS?

a design meeting at CEAS would be cool -- although it'd be just you guys, I
won't be there ;)  
what about an IRC conference some time?

also, a ReplaceTags regexp-rewriting plugin API makes sense.

Notes from a meeting between Michael Parker, Danial Quinlan, and myself:

* Rule type plugins will return code for evaluating the test and calling
got_hit.  check will concatenate and eval this returned code, much like the
existing do_*_tests code does.

* Rule type plugins can store information in the PerMsgStatus.

* We want to reduce the effect that user tests have on the whole mechanism (if
not remove support for user tests entirely).  This may require restrictions such
as prohibiting user tests from having the same name as system rules.

* The "required head/body points" part of autolearn will require rule type
plugins to declare whether each test is header/body.  Is this facility of
autolear needed?

* To simplify the rules mechanism, the "only_these_rules" feature of mass-check
can probably be reimplemented to assign zero scores to those rules it doesn't want.

I definitely cannot see a need for user rules to have the same names as system
ones.  However getting rid of user rules -- I'm afraid I'm not fond of that idea ;)

I'd be fine with dropping the "required head/body points" stuff.

+1 on the "only_these_rules" idea, makes sense.

Sounds good!

> I definitely cannot see a need for user rules to have the same names 
> as system ones.  

Q1: What about user rule score overrides?  Are you counting that as a user rule 
with the same name as a system rule?

Q2: What if someone does make a user rule that happens to have the same name as 
a system rule, either because they don't know the names of all system rules, or 
the new sa_update adds a rule with the same name as a user rule?  

  Treat them as separate rules (separate namespaces)?  
  Give a syntax error, possibly on a rule that has worked for years until SA 
added a new rule with the same name?
  Quietly ignore the user rule?

> However getting rid of user rules -- I'm afraid I'm not fond of that idea ;)

Let me just say that it would be understatement to say I wouldn't be fond of 
the idea.

(In reply to comment #10)
> Q1: What about user rule score overrides?  Are you counting that as a user rule 
> with the same name as a system rule?

Score overrides of system rule would be allowed, but priority changes probably
would not.  Changing tflags multiple would not be allowed, possibly no tflags
changes would be allowed.

If allow_user_rules is off, then we could do the zero-score checks at config
time instead of per message.

> Q2: What if someone does make a user rule that happens to have the same name as 
> a system rule, either because they don't know the names of all system rules, or 
> the new sa_update adds a rule with the same name as a user rule?  

The system rule would win.  This should probably cause a lint error.

Separate namespaces wouldn't work.  If the user config tries to set the score
for a rule, does it affect the user rule or the system rule?

+1, agreed with what John said in comment 11.

in fact, there's a good point there: we should document clearly in the Conf POD
as to which score/tflags/etc. changes are permitted in user prefs, since some
changes may have unexpected results, even in current code. 

any news on this?  I'd be interested in collaborating, as it provides a good API
for the work I'm doing in the re2c branch to override body rules in mainline SA
from a plugin.

I'm attempting to work on the Check plugin stuff at the Hackathon which doesn't
necessarily gate this but will make it much easier.  Come join me :)

hey, I would if I was there ;)

are you on IRC?  how many hours off UTC is Austin?

-0600 CDT which included Austin. TX. 8*))

John -- have you made any progress on this since the WIP?

I'm keen to start getting 3.2.0 into releaseable shape, and I also have a very
fast version of body tests using re2c, sitting in a branch.  it'd be great to
have a "clean" rule-types-as-plugins API for that to use...

I was waiting for you to finish bug 4776 before digging into this.  I was also
waiting for Daniel to remove the non-performing eval tests.

I'll have to schedule some time to dig into this, but I've got about a month's
worth of other projects in my queue.

Closing ancient stale bug.