I noticed that the live wikimedia servers now have a version of the API that respects the maxlag parameter, which is great. Thanks to the people who got that working.
The correct action when getting a maxlag error is to sleep for at least as long as the current lag. A nice feature of the HTTP maxlag error produced by index.php is that an HTTP header 'Retry-After' that directly tells how long to wait.
I looked at the API code this afternoon to see if I could add another field to the error object that would directly include the lag, so that I don't have to parse it out of the text of the info field. I dicovered that the error objects at the moment can only have two fields, 'code' and 'info'.
That explained to me why bug 11404 was resolved the way it was. In that bug, there was no easy way to distinguish between different sorts of internal errors without parsing the info field. It was resolved by changing the error code to directly reflect the type of internal error encountered.
I don't mind writing a patch to permit different instances of UsageException to carry extra information in addition to 'code' and 'info', but I don't want to invest the coding time unless other people think it's worthwhile.
- Carl
Carl Beckhorn schreef:
I looked at the API code this afternoon to see if I could add another field to the error object that would directly include the lag, so that I don't have to parse it out of the text of the info field. I dicovered that the error objects at the moment can only have two fields, 'code' and 'info'.
Since the 'info' parameter is always formatted the same for code=maxlag, parsing it shouldn't be too hard. The documentation [1] should document all possible errors, like the docs for the suggested APIedit modules do (example [2]).
Roan Kattouw (Catrope)
[1] http://www.mediawiki.org/wiki/API [2] http://www.mediawiki.org/wiki/API:Edit_-_Move#Possible_errors
I think we should start using additional error values. One way to do it would be to have an array of additional attributes stored in the usage exception object , and an optional constructor parameter to set it. Alternatively we could have multiple derived exception objects, but i think it would be an overkill.
On Nov 21, 2007 2:13 PM, Roan Kattouw roan.kattouw@home.nl wrote:
Carl Beckhorn schreef:
I looked at the API code this afternoon to see if I could add another field to the error object that would directly include the lag, so that I don't have to parse it out of the text of the info field. I dicovered that the error objects at the moment can only have two fields, 'code' and 'info'.
Since the 'info' parameter is always formatted the same for code=maxlag, parsing it shouldn't be too hard. The documentation [1] should document all possible errors, like the docs for the suggested APIedit modules do (example [2]).
Roan Kattouw (Catrope)
[1] http://www.mediawiki.org/wiki/API [2] http://www.mediawiki.org/wiki/API:Edit_-_Move#Possible_errors
Mediawiki-api mailing list Mediawiki-api@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/mediawiki-api
mediawiki-api@lists.wikimedia.org