Remember that clients should not be depending on the specific query string
data returned inside the query-continue or continue nodes. Clients should
be treating the returned key-value pairs as opaque data to be returned to
the server with the subsequent query.
Interested users may also wish to review the discussion thread from when a
similar change was made last year.[1]
To finish fixing bug 24782[2], Gerrit change 103589[3] changes the names
and values of various items under the continue or query-continue node in
the API response. Specifically,
* list=allimages will always use aicontinue, rather than sometimes using
aistart. The formatting of the value for the modes that formerly used
aistart will differ from that used by the modes that already used
aicontinue.
* list=blocks will now use bkcontinue rather than bkstart.
* list=categorymembers will always use cmcontinue, rather than sometimes
using cmstart. The formatting of the value for the modes that formerly used
cmstart will differ from that used by the modes that already used
cmcontinue.
* list=deletedrevs will always use drcontinue, rather than sometimes using
drstart. The formatting of the value for drcontinue is also changing for
the modes that did use it, and the formats differ between modes.
* list=logevents will now use lecontinue rather than lestart.
* list=protectedtitles will now use ptcontinue rather than ptstart.
* list=recentchanges is changing the formatting of the value of rccontinue.
* list=usercontribs will always use uccontinue, rather than sometimes using
ucstart. The formatting of the value for uccontinue is also changing for
the modes that did use it previously, and the formats differ between modes.
* list=watchlist will now use wlcontinue rather than wlstart.
These changes should be deployed to WMF wikis with 1.23wmf23, see
https://www.mediawiki.org/wiki/MediaWiki_1.23/Roadmap for the schedule.
Also, if anyone is aware of other modules that use a bare timestamp[4] or
other non-unique value as their continuation, please reopen bug 24782 (if
they are in MediaWiki core) or file a new bug (if they are in an
extension). Thanks.
[1]:
http://lists.wikimedia.org/pipermail/mediawiki-api/2013-March/002926.html
[2]: https://bugzilla.wikimedia.org/show_bug.cgi?id=24782
[3]: https://gerrit.wikimedia.org/r/#/c/103589/
[4]: Note prop=imageinfo uses a timestamp, but this is OK as in this case
it is apparently a unique identifier.
--
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
It was noticed recently that these blockinfo properties return the internal
value from the database for the blockexpiry field, rather than formatting
them as does list=blocks. This means the formatting is more difficult to
parse, and that it may differ between installations of MediaWiki depending
on the database backend in use, and it doesn't match the formatting of
other timestamps returned by the API.
If anyone objects to this field being changed to be formatted in the same
manner as the expiry field returned by list=blocks, speak up on the
mediawik-api list.[1]
Thanks.
[1]: https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
--
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation