Re: svn commit: r149224 - in spamassassin/trunk: lib/Mail/SpamAssassin/PerMsgStatus.pm lib/Mail/SpamAssassin/Plugin.pm lib/Mail/SpamAssassin/Plugin/DefaultAutoLearnDiscriminator.pm rules/10_misc.cf rules/init.pre

[Daniel Quinlan <qu...@pathname.com>]

jm@jmason.org (Justin Mason) writes:

> ok, you've convinced me... feel free to refactor that back into core, I
> think.  It seems this *is* a little more "core" than Razor, Pyzor et al.

-1 on refactoring.
 
> (probably easiest to just rename the module back into the
> Mail::SpamAssassin::* namespace, then add the "if defined()" glue after
> the call_plugins call, rather than pushing the subs back into
> PerMsgStatus entirely.)

Oh no, I really like the autolearn code in the plugin.  Factoring it out
was a fantastic idea.  I want to implement a new (slower) plugin to
implement the more optimal autolearning method I proposed and this gives
me the perfect route.

It seems a rather natural extension of the plugin model that we could
have competing methods for the same thing.  For example, I'm looking
into asynchronous DCC, Razor, and Pyzor that would want to be
conflicting plugins.

In terms of handling the autolearn case, couldn't we just have a model
where it's "first come first serve" meaning the first plugin registered
for a particular handler sticks and subsequent plugins that use that API
cannot be loaded unless those subsequent plugins designate that routine
as optional.

Daniel

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

Re: svn commit: r149224 - in spamassassin/trunk: lib/Mail/SpamAssassin/PerMsgStatus.pm lib/Mail/SpamAssassin/Plugin.pm lib/Mail/SpamAssassin/Plugin/DefaultAutoLearnDiscriminator.pm rules/10_misc.cf rules/init.pre

[Michael Parker <pa...@pobox.com>]

On Mon, Jan 31, 2005 at 03:18:03PM -0800, Daniel Quinlan wrote:
> 
> Oh no, I really like the autolearn code in the plugin.  Factoring it out
> was a fantastic idea.  I want to implement a new (slower) plugin to
> implement the more optimal autolearning method I proposed and this gives
> me the perfect route.
> 

Sounds like you like the fact that there is a plugin hook there, not
that it is a plugin.  I agree, lets leave the hook, but the default
code shouldn't be in a plugin.  It saves nothing, and in the long run
makes maintenance and support more difficult.

It's just as easy to call the plugin hook, and if nothing ran then run
our default (inline) code.  Then you don't have to worry about the
plugin in the default case, but it makes it very easy to add on your
own implementation.

Michael