[pLog-svn] r6088 - plog/branches/lifetype-1.2/class/security

[Jon Daley]

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 
more fuzzy.

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