On 12/05/2012 05:54 PM, Chris Steipp wrote:
On Wed, Dec 5, 2012 at 1:11 PM, Matthew Flaschen
<mflaschen(a)wikimedia.org> wrote:
It makes sense for AbuseFilter and Wikidata to
work in conjunction. But
it seems Wikidata should provide a hook that AbuseFilter calls.
I think we agree on this point, although I'll clarify and say I think
AbuseFilter should be calling wfRunHooks, and Wikibase should provide
the functions.
No, we disagree on this.
Wikibase should call wfRunHooks. This is analogous to the way it is now
for regular wikitext.
For example, AbuseFilter has:
$wgHooks['EditFilterMerged'][] = 'AbuseFilterHooks::onEditFilterMerged';
Then, core MediaWiki calls:
if ( !wfRunHooks( 'EditFilterMerged', array( $this, $this->textbox1,
&$this->hookError, $this->summary ) ) ) {
The same general idea should apply for Wikibase. The only difference is
that the core functionality of data editing is in Wikibase.
Thus, Wikibase should call wfRunHooks for this.
What if
someone wants to make spam filter that works differently than
AbuseFilter? For example, it uses its own programmatic rules rather
than ones that can be expressed in the Special:AbuseFilter language.
You are correct, AbuseFilter doesn't currently have hooks to let an
extension run its own logic, but that wouldn't be too difficult to
implement.
I don't think it necessarily needs one. A spam filter with a different
approach (which may not have a rule UI at all) can register its own
hooks, just as AbuseFilter does.
Although I would be interested to know what kind of
rules you have in
mind, since it's certainly possible that we would want to implement it
as a AbuseFilter operation.
I don't have an immediate practical suggestion. But I do know that
modern spam filters use a variety of approaches, including Bayesian
filtering.
Matt Flaschen