Last modified: 2008-03-03 10:09:23 UTC
After r30578 it is now possible to list multiple parameters to &list=usercontribs&ucuser= ... this also creates the possibility for very efficient pseudo-CIDR lookups, eg: &list=usercontribs&ucuser=1.2.3.0|1.2.3.1|1.2.3.2|1.2.3.3|1.2.3.4| ... |1.2.3.255 A typically tested /24 takes only .4 seconds on en.wp, and goes back to at least 2002. However the URI limit at Wikimedia seems to be about 4000 characters, slightly liming the usefulness of this (and using format=json in a <script> precludes using POST). Could this behavior, then, be supported natively? Either via CIDR formatting? say up to /24 for normal users, and maybe as far as /20 or even /16 for bots (which could take over a minute): &list=usercontribs&ucuser=1.2.3.0/24 Or perhaps some sort of prefix parameters: &ucuserprefix=1.2.3. (though this may not be optimal) Whichever is most efficient to the current design of parallel user lookup, while allowing a shorter URL.
I'll look into this.
I implemented your latter suggestion (ucuserprefix) in r31312. Keep in mind that ucuserprefix doesn't take multiple values (for efficiency reasons), also works for regular user names and overrides ucuser if present.
Seems to work great for CIDR! One problem I've run in to though using ucuserprefix for regular user names... how do you encode spaces? Compare: http://en.wikipedia.org/w/api.php?action=query&list=usercontribs&ucuser=Tim_Starling http://en.wikipedia.org/w/api.php?action=query&list=usercontribs&ucuserprefix=Tim_Star http://en.wikipedia.org/w/api.php?action=query&list=usercontribs&ucuserprefix=Tim+Star http://en.wikipedia.org/w/api.php?action=query&list=usercontribs&ucuserprefix=Tim%20Star http://en.wikipedia.org/w/api.php?action=query&list=usercontribs&ucuserprefix=Tim%2520Star http://en.wikipedia.org/w/api.php?action=query&list=usercontribs&ucuserprefix=Tim%26%2332%3BStar
(In reply to comment #3) > Seems to work great for CIDR! One problem I've run in to though using > ucuserprefix for regular user names... how do you encode spaces? > That was a bug, fixed in r31489. Tim%20Star works now.
