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 _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
