On Tue, Jun 24, 2008 at 01:05:19PM +0100, Jools Smyth wrote:
I hope this is allowed here, but I have recently
written a Perl module to
interface with the MediaWiki API, and am after users to try it and let me
know what works/doesn't etc.
The module is not on cpan yet (Awaiting an account), but can be downloaded
from
http://www.exotica.org.uk/wiki/User:BuZz/MediaWiki::API
Ironically, I also have a Perl module named Mediawiki::API at
svn co
svn://hemlock.ts.wikimedia.org/cbm/subversion/mediawiki-api
Mine is somewhat more complete in terms of queries, but I don't have
editing support written yet.
Perhaps we can work together to make a single library. I have been
planning to work on rewriting mine (it was originally proof-of-concept
code, and significant reorganization is needed). My library is
field-tested in VeblenBot and the WP 1.0 bot on enwiki.
I'll be glad to dual-license my code in both GPL and the Perl license.
I noticed your library is not very robust about handling errors from the
API. I have found through experience that the following error situations
have to be expected and handled when dealing with the API:
0. The server may be temporarily unavailable, or the DNS may
temporarily fail to resolve. This is true for any web-based service.
The query has to be repeated if the server is temporarily unavailable.
1. The squids may return an error message, which is marked by an HTTP
'x-squid-error' header. This means the query must be repeated.
2. You will quite routinely get a 0 byte response with a sucessful HTTP
status code. This means the query must be repeated.
3. You need to use a maxlag= parameter, and detect when the maxlag
is exceeded. If it is exceeded, the query must be repeated after the
appropriate delay.
4. Rarely, you may get a truncated XML response, which causes
the XML parser to throw an exception. This means the query must
be repeated.
You can see this error handling in the poorly named 'makeHTMLrequest'
and 'makeXMLrequest' functions in my API.pm. These should be
'makeHTTPrequest' and 'makeXMLrequest', respectively.
- Carl