On Mon, Mar 23, 2009 at 1:23 PM, Eric Florenzano <flo...@gmail.com> wrote:
>
>> James, this is something that can be added later. This is progressive
>> enhancement of the functionality and *if* (not a given) we take what's
>> in #9282 now without blocking on every feature that might be possible or
>> popular, it won't be a shame. It isn't a half-baked implementation, it's
>> just leaving the door open for more additions in the future.
>
> I don't really understand this argument. Maybe I'm not parsing it
> correctly, but I read this as "Your implementation is good, but let's
> not add it now so that we can add it later", which seems a bit
> strange.
>
I'm a little confused about the disagreement here. Perhaps I'm wrong,
but I get the sense that people are asking for two different things.
1. It seems that some are expecting the base CommentModerator to use
Akismet by default. That is a bad idea IMO. The patch as-is is correct
here.
2. While others are expecting a subclass of CommentModerator that uses Akismet.
Whether that happens or not, I don't really care. But whether it
happens when this patch is committed or later shouldn't really effect
whether this patch is ready or not.
Btw, while we're on the subject, this (hopefully option 2 above) would
make implementing Django-Spambayes [1] (a comment filter built on top
of the SpamBayes email filter) easier - with one exception. SpamBayes
is a training system. For the system to work, it needs to be trained
with both "ham" and "spam". Then there is the third state "unsure"
which goes into moderation. The user should then be able to move a
comment between any of those 3 states (retraining the system with each
move). Having only a two state system ("ham" and "unsure") with the
"spam" automatically deleted makes this kind of hard. I realize I
should be able to alter that in a subclass, but it would be nice if
the base class at least considered that a subclass might want to act
that way.
Perhaps an attribute on the class called "delete_spam" (or whatever
color you want to paint that bikeshed) which turned on or off
automatic deleting of unwanted messages. So setting "delete_spam" to
True would get the same behavior we have now while setting it to False
would leave the message in the db, set "is_public" to False, but also
recognize that it has already been moderated (I believe
`comment.is_removed = True` does that).
[1]: http://code.google.com/p/django-spambayes/
--
----
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
