[pLog-svn] r6088 - plog/branches/lifetype-1.2/class/security
plogworld at jon.limedaley.com
Thu Nov 29 23:46:42 EST 2007
oops, never sent this. My next email supersedes this one, but since it
was already written, here goes...
On Thu, 29 Nov 2007, Paul Westbrook wrote:
> 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.
Yes, I understand this part.
> Here is a potential proposal that would solve this problem, and not
> require the filters to be run twice
Sounds good so far...
> 1) Make it possible to have a plugin return the fact that some state has
> been persisted.
> 2) Set this as a property of the comment.
> 3) If one of the following plugins wants to delete the comment, it will call
> the Delete() method.
> 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.
Starting to lose me here. I think I get it from a sort of
abstract view, but in terms of what it would look like in the code, I am
> 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
This way makes more sense to me. But, I am not sure if the
comment object exists like that - I think just the commentText,
commentUrl, etc. get passed to each filter, and not the comment object.
More information about the pLog-svn