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 _______________________________________________ infrastructure mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/infrastructure
