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

[Sean True]

OK, not really, but at least you are reading the rest of the message.
Mark and I are ruminating about plugins and add on filters for
Spambayes/SpamAtBay/InBoxer.

-- Sean

> -----Original Message-----
> From: Mark Hammond [mailto:mhammond at skippinet.com.au] 
> Sent: Monday, August 04, 2003 7:45 PM
> To: 'Sean True'
> Subject: RE: [Spambayes-checkins] 
> spambayes/Outlook2000/dialogsasync_processor.py, NONE, 1.1.2.1
> 
> 
> > Because I'm getting requests left, right, and center from
> > developers who
> > don't want to work in the middle of the tree. They want to
> > add SPEWS/RBL for
> > testing; they want to add logging, mail forwarding, 
> implementation of
> > business logic. They want a platform, not just a mail filter.
> 
> Just so I am clear here - requests from who exactly, and how 
> do you intend
> satisying their requests?  Will these users actually write 
> "code", or will
> it still all be configured via a UI.
Requests from current and potential SAB customers. Who will write actual
code, including maybe their own UI.


> 
> 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. ;-)

> 
> Of course, if you intend exposing the same level of code as 
> you sent me as
> an example to the users, then I can see the benefit.  
> However, I am not
> convinced that the model we are then exposing is correct - I 
> would not be
> happy writing my own personal rules that way.
I anticipated that I could wrap your filter module in this code, and that it
would then be one of many alternative non-bayesian filters available for a
person to pick and choose from. My hope was to have a level playing field,
whatever the exact API. My current sketch is just a sketch, although it has
made it easy to do some cool stuff.

> 
> > From my point of view, there are two large pieces of 
> engineering here:
> >
> > The baysian scoring code.
> > The Outlook integration code.
> >
> > At "the end of the day", I'd like to see a plugin interface
> > for the Outlook
> > code that would run the spambayes engine itself as an 
> external plugin.
> >
> > Think Photoshop, I guess.
> 
> > As for important, I see it as a giveback. We're going to
> > develop, doc, and
> > maintain a platform plugin API for the commercial product,
> > and would like
> > people who don't want to spend $ to be able to use plugins --
> > and write
> > them.
> 
> Except it isn't really clear how it will actually help our open source
> project in a useful way.  Unless we also go to the effort of 
> supporting and
> exposing the plugin mechanism it just becomes complexity in 
> our code for
> something we don't use.  Unless of course you were going to 
> contribute code
> to actually make these filters useful to us too <wink>.
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.

> 
> If we *do* support a "filter" API, I would like to see one 
> that at least the
> other SpamBayes projects could use.  I see no reason 
> pop3proxy etc could not
> use the exact same system as we use.  But I am reluctant to sanction a
> plugin API that I can't see how it would be used without huge 
> effort from
> me - and in which case I may as well spend that effort in a 
> direction I
> prefer.
Mmm. I was hoping for _zero_ effort from you. I need you to be fixing bugs
in the parts of the system that make my head hurt. <grin>

> 
> How about we move this discussion to spambayes-dev, and see 
> if we can get
> extra interest from anyone else on the project?  I think the 
> concept is
> sound, so see no reason we can't aim at something useful to a 
> few of us :)
> 
Yes, indeed. Done. Moved.


> Thanks,
> 
> Mark.
> 
> 

-- Sean