On 06.12.2012 01:55, Chris Steipp wrote:
The same
general idea should apply for Wikibase. The only difference is
that the core functionality of data editing is in Wikibase.
Correct, and I would say that Wikibase should be calling the same
hooks that core does, so that AbuseFilter can be used to filter all
incoming data.
That would be great, but as I pointed out in my original mail, not really
possible: the existing hooks guarantee an EditPage as a parameter. There is no
EditPage when editing Wikibase content, and I can see no sensible way to create
one for this purpose.
If Wikibase wants to define another hook, and can
present the data in a generic way (like Daniel did for content
handler) we can probably add it into AbuseFilter.
We can present (some of) the data as plain text, but that removes a lot of
information that could be used for spam detection. Maybe AbuseFilter is flexible
enough to be able to handle more aspects using "variables". But that would
require Wikibase to know about AbuseFilter, and specifically cater to it (or the
other way around).
But if the
processing is specific to Wikibase (you pass an Entity into the hook,
for example), then AbuseFilter shouldn't be hooking into something
like that, since it would basically make Wikibase a dependency, and I
do think that more independent wikis are likely to have AbuseFilter
installed without Wikibase than with it.
No, that is not a dependency in the strong sense; You could easily run one
without the other. But it does imply knowledge. So, should Wikibase have
knowledge of, and contain code specific to, AbuseFilter, or the other way around?
Honestly, I don't like either very much.
> 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.
But then Wikibase needs to know about each of them, and implement hook handlers
for each. Or am I misunderstanding you?
So... we are still facing the Glue Code Dilemma.
-- daniel