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? I don't want multiple filter algorithms to be in the UI. 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. 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. (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, and you have to make the code more complex. 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.) > 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. 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. > 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. And it's also pointless because Spamassassin is clearly superior to Bogofilter. -- Ettore Perazzoli <[EMAIL PROTECTED]> _______________________________________________ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
