Wiki extension request

Adam Williamson awilliam at redhat.com
Mon Jan 17 17:15:16 UTC 2011


On Thu, 2011-01-13 at 11:09 -0600, Ian Weller wrote:

> If you only need multi-category searching in the API, that extension
> won't help any, since it doesn't appear to expose anything over the API.

OK, thanks.

> Using the API, however, you can get a list of pages within categories,
> and then just use whatever programming language you're using to merge
> them together on the client side, not the server side. You can read the
> docs for list=categorymembers on fp.o/w/api.php, or we can hack on it at
> FUDCon at some point.

Sure, the only issue that we're worried about with that is that it will
lead to unnecessarily complex implementation issues. The types of
searches we want to do for the test case categorization system are
pretty static - it'll always be a certain type of category combination
that needs querying - so having each client implement it client-side
seems like unnecessary work and may lead to more breakage than
necessary, so we thought it'd work best to present a common interface
for doing this, in some way - a recommended method for external tools to
use which will be the same for all of them, so we can make sure it's
always robust.

James has volunteered to look at perhaps implementing what we want into
python-simplemediawiki , which might suffice - we could set up a method
in that, and then just recommend all external tools use that method to
do the test case discovery.

> DPL does the same thing, but can be included in any page on the wiki.
> That might be useful, if you want that information to show up on the
> wiki, but if you're still just wanting to use the API and have it show
> up elsewhere, it's not useful at all.

yeah, that may be useful in some way, but it's not really the goal here,
so it's probably not worth looking at unless and until we have some
specific need for it.

> On a more general note, I think we are somewhat shy of having too many
> extensions on our wiki instance, because compatibility can break on wiki
> upgrades and can also slow down the wiki (one of the main reasons we had
> such slowdowns with MoinMoin, IIRC, was too many plugin/extension type
> things). Additionally, I've been talking with smooge to get MW upgraded
> to 1.16 soon, which will include highly improved API support.

Cool, thanks!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



More information about the infrastructure mailing list