Theo Van Dinter writes:
On Sat, Feb 25, 2006 at 12:52:16AM -0800, Loren Wilton wrote:
Without looking at the code, and as something of an outsider, some thoughts
that may be useful:
:)
1. Is there any notable rule efficiency difference between being an eval
and being a plugin?
One big plugin would be better than the current split. The current
split has no solid technical rationale behind it.
- allows eval rules to not be loaded. arguably, most of them will always
be
enabled, but some could be disabled. DNSEval, for instance, is only
useful
in net mode. If
On Sat, Feb 25, 2006 at 12:52:16AM -0800, Loren Wilton wrote:
Without looking at the code, and as something of an outsider, some thoughts
that may be useful:
:)
1. Is there any notable rule efficiency difference between being an eval
and being a plugin?
The results are exactly the same.
On Fri, Dec 30, 2005 at 03:04:57PM -0800, John Myers wrote:
You either have 1 big plugin, which may as well be EvalTests, or you have
many plugins, one for each function. The current split is somewhere in the
middle where I tried grouping semi-related functions together by rule type.
One
On Fri, 30 Dec 2005, Loren Wilton uttered the following:
This is along the lines I've been considering since I first started writing
rules for SA. Personally, I'd much prefer that the .cf files NOT contain
pure perl, for two reasons:
one, it seems easy enough to be able to do horrible
You can do that with the plain regex rules thanks to the experimental
and rather loony (?{...}) and (??{...}) constructs.
Well no. You could do that on 2.6x, and I used that for some very valuable
rule development tools. That ability was removed in 3.x.
Loren
On Fri, 6 Jan 2006, Loren Wilton uttered the following:
You can do that with the plain regex rules thanks to the experimental
and rather loony (?{...}) and (??{...}) constructs.
Well no. You could do that on 2.6x, and I used that for some very valuable
rule development tools. That ability
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
John Gardiner Myers writes:
Loren Wilton wrote:
Others have suggested adding new basic rule types with plugins, which is
probably not a terrible idea. But on the other hand, I'd suggest that
cleaning up internal structure as necessary to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Daniel Quinlan writes:
John Gardiner Myers [EMAIL PROTECTED] writes:
I think one weakness in the design of eval tests in general is that
their definition is split into two different places, a function
definition in some .pm file and a
Loren Wilton wrote:
Others have suggested adding new basic rule types with plugins, which is
probably not a terrible idea. But on the other hand, I'd suggest that
cleaning up internal structure as necessary to make it easy to add new types
internally might be a better long-term investment.
of things
in tvd-evaltoplugin is not final, it's just a working version that doesn't
have EvalTests.
I recall that there was an observation on the dev list that the
EvalTests.pm had a different API than plugin-provided eval tests. It is
worth making the APIs the same and it is possibly worth
John Myers [EMAIL PROTECTED] writes:
SpamAssassin is in serious danger of contracting plugin disease.
The fact that people are seriously talking about making
PerMsgStatus::check() a plugin is Exhibit A. The idea is itself a
reduction to absurdity.
No, moving most of check() to where the
Daniel Quinlan wrote:
No, moving most of check() to where the check function can be placed in
different plugins is a very good move. This allows us to provide
options for how check() works. For example, trying out Bayesian
decision-making, decision tree for faster operation, etc.
Moving
John Gardiner Myers [EMAIL PROTECTED] writes:
I think one weakness in the design of eval tests in general is that
their definition is split into two different places, a function
definition in some .pm file and a function call in some .cf file. The
.cf file isn't very amenable to
Converting sections of tests into plugins where some people will want to
disable the entire set due to performance, memory, or similar
constraints (i.e., Bayes tests, network tests, special functionality,
etc.) does make sense. However, converting individual (or nearly
individual) tests that
I'm currently -0.9 on the plethora of plugins in the tvd-evaltoplugin
branch. This change appears to be adding quite a bit of complexity for
little to no practical benefit. It appears to be trying to separate
code out into individual plugins just for the sake of separating code
out
On Wed, Dec 28, 2005 at 03:13:49PM -0800, John Myers wrote:
I'm currently -0.9 on the plethora of plugins in the tvd-evaltoplugin
branch. This change appears to be adding quite a bit of complexity for
little to no practical benefit. It appears to be trying to separate
code out
17 matches
Mail list logo
