Re: [Evolution-hackers] spam filtering

[Radek Doulík <rodo ximian com>]

On Thu, 2003-10-02 at 18:41, Ettore Perazzoli wrote:
> Hello,
> 
> thanks for looking into this.
> 
> > Plugin will be shared library which will be loaded by dlopen/dlsym.
> > Evo will get SpamFilterStruct by dlsym, check api_version and then use
> > supplied methods.
> 
> What happens if there are multiple plugins installed?  What's the UI
> going to look like?  How are they going to be executed?

The UI is described in my mail, in 1st section. You may select
filter(plugin) in Settings dialog. It will default to 1st installed
filter or to a filter linked to evo.

> I don't want multiple filter algorithms to be in the UI.

There nothing different in the UI (besides possibility to have
different/specific options)

>   It has to work
> out of the box, and it must provide nothing but the very basic
> settings.  I don't want users to have to know about Spamassassin vs.
> Bogofilter or whatever, because they really don't care.

They don't have to care. It has good defaults, you have to care only if
you don't like the default filter used. Then you have a choice to use
different plugin.

> So don't waste time to make it pluggable and generic until you have a
> *good* implementation that works with Spamassassin.  At that point we
> can decide whether the pluggability is worth the added complexity or
> not.

I am not wasting time. Making it plugable lets me to define simple API.
If I don't do it that way, it may be impossible to make it plugable
later and will cost us more time.

> (It is not true that it's just the same amount of work.  With plug-ins
> you are adding another instance of things that can go wrong, you make it
> harder to debug,

Why?

>  and you have to make the code more complex.

I don't see any added complexity there. Also I will be hacking this so
please keep me my freedom of choice how to implement it.

>   And right
> now it's completely pointless given that there are basically only 2
> filters that people will want to use, and one of them is clearly
> superior to the other.)

There are at least 3 major one people are using (bogofilter,
spamassassin and spamprobe).

> > Spam will be identified by check_spam method, spam status changes will
> > be reported to filter by report_[no]spam methods. Plugin may or may
> > not provide configuration gui for Settings dialog.
> 
> This sounds like UI hell to me.

I am not sure I understand what do you mean here.

> Again, please focus on making a good spam filter that uses Spamassassin
> -- as per my directions.
> 
> > >From discussion on the mailing list, it looks like everybody is for
> > using vFolder for Spam folder. I am not sure if it's that great.
> 
> Using a vfolder makes it simpler to move messages between their original
> folder and the Junk folder, and vice versa.  So for example if a message
> went into the Junk folder and you want to mark it as non spam, with a
> vfolder you just mark it so, and that will cause it to "move" to its
> original position without any actual data being moved around.

I am of course aware of this. What I was not sure about was the
performance of vFolder vs. moving of 10% spam messages. Michael
clarified this and Jeff brought another reasons why using vFolder will
be useful.

> > If we put them in vfolder, are they going to be visible in the source
> > folder?
> 
> No, the mail display should hide messages marked as spam, just like it
> currently hides messages marked as deleted.
> 
> > I plan to write Spamassassin and Bogofilter plugins (I expect it may
> > work faster, but I tried only spamassassin so far).
> 
> This is pointless.  Spamassassin and Bogofilter are both command-line
> tools, so you can have "pluggability" without having separate shared
> libraries for them.  You can just have GConf keys for the commands to
> invoke.

Your "pluggability" using gconf keys doesn't seems clean to me. also
bogofilter is written in C so it may be possible to build plugin which
will not need exec bogofilter command line tool. Also IIRC spamassassin
has a library to communicate with spamassassin's daemon.

> And it's also pointless because Spamassassin is clearly superior to
> Bogofilter.

I am not yet sure about this.

Cheers
Radek