[spambayes-dev] RE: Mark and Sean stand around the water cooler discussing plugins, and call each other names.

[Mark Hammond]

> > If the latter and via a UI, then I don't see the advantage,
> > as we don't need
> > a flexible system; we just need one as good as the UI.  In
> > the first stages,
> > when there aren't that many "competing" filters, and where
> > the rules can't
> > get *too* complex and still be reflected in a UI, I don't see
> > the advantage.

> Agreed. The idea is to empower a developer to write simple code. If he
> want's UI, we may be able to offer a simple framework, but I
> have no itch to
> write a generic UI system for every developer. Unlike some
> people who are
> more ambitious than I. ;-)

Note that the filtering ideas we have been discussing privately are
completely separate from the UI work I am doing.  I don't see how a "generic
filter API" could be built on our budgets ;)

> Indeed I was. The idea is to have the ability to move source
> code filters
> back and forth between the supported platforms, including any other SB
> systems that need one, and any non-SB systems would be
> welcome to add the
> architecture. Of course, they would need Python. What a shame.
> I'm absolutely in favor of supporting it. I would love to
> write a whole
> series of little plugins that would do interesting things.

I am afraid I am still not clear on exactly what you are proposing.

Initially I thought you were talking about "just" a generic plugin
mechanism, but now it seems you are also talking about specific changes to
the codebase to provide additional, concrete filtering capabilities.  Can
you outline exactly what changes you are proposing to add (ie, exactly what
changes the user would see)?

Thanks,

Mark.