You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by Daniel Quinlan <qu...@pathname.com> on 2005/02/01 00:10:46 UTC

Re: optional vs. standard plugins

(new Subject:)

Michael Parker wrote:

>> Which might be ok, but I can promise you that someone is going to go
>> through and either rm init.pre or comment out every loadplugin line
>> and then start asking questions about why their system isn't
>> autolearning.

Losing autolearning if someone deletes init.pre is completely
acceptable.  Autolearning *should* be optional and pluggable.  Making it
pluggable allows people to experiment and try out other autolearning
mechanism and I suspect we'll see some usage of the API soon.  ;-)

We could also add a new autolearn state like "notloaded".

Theo Van Dinter <fe...@kluge.net> writes:

>> I think we should shoot for a goal of when all plugins are disabled
>> the system should still do the right thing.  If that means that we at
>> least provide a default inline that can be overridden by a plugin,
>> then that is how we should do it.

Not autolearning if it has been disabled *is* the right thing.  Things
work fine if autolearning is off.

Also, our current autolearning code does not improve results by that
much in practice (which is why it needs to be revisited and other ways
to autolearn to be explored).  See Gordon C.'s paper for those results.

> I'll provide a slightly different version: for code that people are
> likely not to override (such as autolearning), we should probably just
> have it be in the code by default and let plugins override as
> necessary..

I disagree in this case, although I think there are probably some cases
where things are likely to not be overridden.  Users are going to
encounter plugins and they're now a major part of basic SpamAssassin
functionality (much like Apache httpd, incidentally), we should just
document things well enough.  If people comment out stuff without
thinking, then there's not too much we can do about it.

For plugins that are likely to not be overridden, I'd be fine with
splitting init.pre into two or more files, like:

  standard.pre
  optional.pre
  experimental.pre

or whatever.  That would go a long way to guiding people as to how
seriously they need to think before commenting stuff out.

Of course, I agree ** 100% ** that everything should work as in "not
fail" if all plugins are commented out.  There might be a few cases
where plugins have cross-dependencies, but we should make sure our code
deals with those and acts appropriately (warn, die, dbg, or whatever,
but *no* straight Perl interpreter errors!).

Also, putting a line next to the AutoLearnThreshold load line such as:

# at least one AutoLearn plugin needs to be loaded for autolearning to work

is more than enough to prevent a stupid commenting out.  If people just
comment stuff out without thinking or delete init.pre, we can't save
them.

Daniel 

-- 
Daniel Quinlan
http://www.pathname.com/~quinlan/