https://bugzilla.wikimedia.org/show_bug.cgi?id=14425
--- Comment #3 from Roan Kattouw <[EMAIL PROTECTED]> 2008-11-18 13:36:17 UTC --- (In reply to comment #2) > roan, an inefficient implementation would still help me a lot, so i hope you > might reconsider. I meant inefficient on the server side. So I'm sure it would help you a lot, but it would also overload the database servers. > i am writing an application which, for a given article, acquires lists of peer > articles in some of its categories. without paging, this means making one > asynchronous HTTP connection per category, which breaks badly on "Amtrak" > (with > over 60 categories, many of which have almost no members). the order the > contents were returned is less important than a big cut in the number of > connections i need to make. I understand that ordering isn't important to everyone, but it's needed to make query-continue possible. > by executing action=query&generator=categories&prop=categoryinfo in advance, i > can pick out which categories have suitable numbers of pages in them to > proceed > to the member listing step. this means that a category with hundreds of > members > could come last in the list, giving me access to a good subset of the category > members in a single HTTP request (several if i page on through the results, > but > still not 60). > Sounds like a good solution. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
