http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4776
------- Additional Comments From [EMAIL PROTECTED] 2006-02-03 19:32 ------- (In reply to comment #7) > Imagine an agressive Short Circuit Spam module for users who don't mind > dropping > a few msgs through the cracks, or perhaps it's a Short Circuit Ham module that > leans a little the other direction. [...] > Users should have the freedom to choose how agressive or careful they want to > be > with check, and we should provide an interface for folks who want to modify > that > behavior to fit their situation or message flow. So instead of one parameter, required_score, which adjusts the FP vs. FN tradeoff, we would have two different parameters, both adjusting the FP vs. FN tradeoff in different ways? How is a user or admin supposed to figure out which parameter to adjust and by how much? You are proposing an unmaintainable and unsupportable mess. > John, I think the reasoning you presented in your -1 (was that a veto?) is > exactly why we want an interface like this, it gives you choices. I strongly > disagree with the whole pick an implementation and make everyone else follow > it, > that is the wrong approach. By giving choices, one necessarily takes away other choices. By providing a plugin interface for X, future versions of SpamAssassin are then constrained to supporting plugins implementing X and SpamAssassin is foreclosed from using knowledge about how X is done or implementing anything that requires changes to the interface to X or whatever the various implementations of X call. (And yes, "-1" means "veto".) > There is no reason why we can't implement a rule type plugin that adds > additional plugin calls to do exactly what you describe, that is what makes > the > interface work so well. As to how stable the check_main interface is, I would > call it very stable. So you would call do_head_tets, do_head_eval_tests, etc. stable interfaces? That would definitely foreclose implementing many possible forms of short circuiting, as well as rule type plugins. If the interface is stable, that means future changes to SpamAssassin are constrained to making sure the implementation of Mail::SpamAssassin::Plugin::Check in the proposed patch continues to work without changes. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
