On Wed, Dec 5, 2012 at 3:34 AM, Daniel Kinzler
You really want the spam filter extensions to
have internal knowledge of
Wikibase? That seems like a nasty cross-dependency, and goes directly against
the idea of modularization and separation of concerns...
We are running into the "glue code problem" here. We need code that knows
the spam filters and about wikibase. Should it be in the spam filter, in
Wikibase, or in a separate, third extension? That would be cleanest, but a
hassle to maintain... Which way would you prefer?
I think Daniel has correctly stated the problem.
One of the directions of the Admin Tools project is to combine some of
the various tools into AbuseFilter, so I think it's safe to assume
that AbuseFilter will be around and maintained for some time, and
Wikidata could easily use the hooks it provides to do a lot of the
work providing the interface.
It makes sense for AbuseFilter and Wikidata to work in conjunction. But
it seems Wikidata should provide a hook that AbuseFilter calls.
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.
If Wikidata exposes an API, AbuseFilter and other extensions can use it.