Hello,<br> Sorry that I am joining this discussion late.<br><br>As mentioned above, the reason that I made this change was that the bayesian database was getting poorly trained. I had cases where the same message was not being caught by the bayesian filter, and being trained as ham, and then failing some other spam filter, which deleting the message. This was happening several hundred times with the same message, so the bayesian database was getting really screwed up.
<br><br> The root of this problem was that that the message got removed from the database, so I (the user) had no way to help fix the database.<br><br> Here is a potential proposal that would solve this problem, and not require the filters to be run twice
<br><br>1) Make it possible to have a plugin return the fact that some state has been persisted.<br>2) Set this as a property of the comment.<br>3) If one of the following plugins wants to delete the comment, it will call the Delete() method.
<br>4) In this method it checks to see if the "something has been persisted" bit and doesn't actually delete the comment, but just hides it.<br><br><br>An alternative to this is to have the comment keep a reference to the filters that have persisted something. In the delete method, before the comment is deleted, all of the filters are given a chance to clean up their state.
<br><br><br>--Paul<br><br><div><span class="gmail_quote">On 11/29/07, <b class="gmail_sendername">Jon Daley</b> <<a href="mailto:plogworld@jon.limedaley.com">plogworld@jon.limedaley.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Fri, 30 Nov 2007, Mark Wu wrote:<br>> What you do is make the bayesian filter work worse not better.<br>><br>> There are several plugins use pipeline filter, we take authimage,<br>> host-block, anti-dns-spam, content-filter as exmple:
<br>><br>> If one of them failed, you ask baysianFilter to training the comment as a<br>> spam, It is not a good idea.<br>><br>> 1. Authimage failed: it is due to user input wrong code, but he is not spam.<br>
I disagree. What percentage of the auth image failures are due to<br>being a spammer versus a user. If users are failing a lot, this plugin<br>should be removed from the system. The whole point is that spammers fail
<br>the auth image, right?<br><br>> 2. host-block: some one keep post something from some IP, but the content is<br>> not spam, and the "IP" yes .... and our bayesian does not training IP<br>> 3. anti-dns: the same as host block
<br> I disagree again. I guess if you are trying to block your friends<br>rather than spammers, you would be correct. I think the point of the host<br>block is to try to catch the cases where the bayesian filter missed the
<br>spam.<br> I guess it is a disagreement about how the bayesian filter should<br>work. For my email, I train every single spam and non-spam that I get for<br>the last three years. I am not really affected by the so-called image
<br>spams, with random text, etc. My bayesian filter happily trains away, and<br>blocks pretty much all of those sorts of spams. Bayesian filtering works<br>better if it is helped, not worse. It is a matter of statistics.
<br><br>> 4. content filter: We just don't want some "word" to post into our comment,<br>> but it is not spam.<br> This one is your best argument, but I still say that you should<br>let the bayesian filter train on everything and it will come out the best.
<br>Your method has the filter trained the opposite way - the bayesian filter<br>takes a comment that fails the auth image and trains it as non-spam.<br>Which is worse?<br><br>> And, If you DO reallty won't to solve the order problem, we should add a
<br>> priority to register filter , like<br>><br>> $registerFilter( $filter, $priority )<br>><br>> And, before we run the process(), we need to sort the global filter array()<br>> by priority. That's the right method.
<br>><br>> Becasue we can always put the baysianFilter in the last order everytime.<br> Yes, but I think there could be other plugins that would want to<br>be treated "special" and run last. Maybe plugins could request to be run
<br>at the end or something.<br><br>> Nit just run them twice, and add a "hacky" secondRun flag there to avoid<br>> filter to something.<br> I think the $secondRun flag could be replaced with<br>$previouslyRejected, if you would like, since I think that since the
<br>bayesian filter always runs first, the only time previouslyRejected will<br>be set to true is when it is the second run.<br> By the way, if we go with your code, you should probably use the<br>previouslyRejected flag.
<br>_______________________________________________<br>pLog-svn mailing list<br><a href="mailto:pLog-svn@devel.lifetype.net">pLog-svn@devel.lifetype.net</a><br><a href="http://limedaley.com/mailman/listinfo/plog-svn">http://limedaley.com/mailman/listinfo/plog-svn
</a><br></blockquote></div><br>