Hi! Please let me introduce myself: I am Freya and I'm the latest addition to the Outerthought team.
As a getting-up-to-speed project, I'm currently integrating Mollom - a webservice for spam filtering - in a blog comments extension in Daisy - the extension you would be using when leaving a comment on this blog.
Mollom is easy to use (it's based on XML-RPC calls) and works like a charm: if a comment is doubtful, it presents a captcha, it keeps statistics, and gradually a Bayesian database is built so more and more spam should get captured and ham gets through without captcha. Despite a few bugs (which were fixed by Mollom mostly on the day itself!) the integration was really easy - a great way for me to learn Daisy and its extension framework.
However, as it says on the website: Mollom is currently in public
beta. So once in a while, things go wrong
.
Recently I had 2 days where I could not reach any Mollom server, which raised a
few questions I wanted to share here.
If Mollom is down, what should we do with the comments posted at that time? Post the comments anyway, thereby letting the door wide open for spam? Disabling to post any comment and thereby keeping regular blog readers from posting a comment? Or should I opt for the solid engineering approach, and start queueing the comments and process them afterwards? In this case, we should also wonder: if Mollom is down and vast amounts of comments were post during this period: how is Mollom going to react if we send them all at once? What if all blog- and CMS-platforms would implement such a queuing feature, and start submitting unchecked comments to Mollom once it becomes available again?
I'm looking for a best practice here, so leave a comment (unchecked by Mollom ... yet) if you have an idea. And yes, the plan is that the entire blog (+ comments) application will be made available as well, as a simple yet non-trivial example of the Daisy extension framework.