Hi Brad, Our code hardcoded "rcstart" in both string value and C++ class member name. This change is really a breaking one to us. Could you tell me when this is released to *wiki? (right now, I'm thinking a quick dirty fix, hope it can be done in 1-2 days, and I do want to switch to new "continue=" style, but that takes longer, 1-2 weeks, I'm afraid) Thanks On Thu, Mar 21, 2013 at 5:03 PM, Brad Jorsch <bjorsch(a)wikimedia.org> wrote: -- Jiang BIAN This email may be confidential or privileged. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it went to the wrong person. Thanks.

On Thu, Mar 21, 2013 at 8:03 PM, Brad Jorsch <bjorsch(a)wikimedia.org> wrote: That this is considered backwards-compatible confuses me. Are there other keys that we should we ignore in a typical API response? Jim

On Fri, Mar 22, 2013 at 6:52 AM, Brad Jorsch <bjorsch(a)wikimedia.org> wrote: Can I understand that once the bug is fixed on test2wiki, it will be deployed to *wiki and other media wiki sites immediately? or is it released on a regular base (e.g. 2 weeks later? - in this case, it means we have at least 2 weeks to fix our code) And when deploying the new release, is it done to all sites at once or one-by-one in a release window? (if the release proces last for a while, e.g. 1-2 days, our change need to handle both new style and old style, right?) Here is more background of our broken: (sadly) our code DO look into both the value of "rcstart" (e.g. "2013-03-23T02:53:28Z") and the attribute name itself ("rcstart"). Now I understand we should not do that. But it is not easy for us to have a quick fix this time, the parsing of XML is done by another library which is much older, and hard to change. To have a complete fix (I mean respect the spec, not looking into the attribute names or values), we need 1-2 weeks at least. So I'd prefer a quick fix if something still works. It looks to me I can still sends out rcstart by strip the "|?????" from rccontinue value: e.g. https://test2.wikipedia.org/w/api.php?action=query&list=recentchanges&a… Could you confirm this is what I can expect with the release of 1.21wmf12? Thanks -- Jiang BIAN This email may be confidential or privileged. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it went to the wrong person. Thanks.

On Sat, Mar 23, 2013 at 9:15 AM, Carl (CBM) <cbm.wikipedia(a)gmail.com> wrote: Perhaps it's not clear in the documentation, but I've always written my continue functions to do something like the following, which seems to accord with what Brad is saying. for (JSONObject moduleObject : prevResult.getJSONObject("query-continue")) for (String moduleParam : moduleObject.keys()) nextParams.put(moduleParam, moduleObject.getString(moduleParam)); This has the advantage of being query-independent, fairly simple, and not being broken when continue parameters change, documented or not. Cheers, -Madman/ea

On Sat, Mar 23, 2013 at 11:15 PM, Brad Jorsch <bjorsch(a)wikimedia.org> wrote: Exactly - putting ucstart into query-continue was already a breaking change whenever it was done, because the documentation states that uccontinue is the parameter that is used for continues. To fix the bug 24782, what is happening is essentially that the API is going back to what it should have been doing all along, using e.g. "uccontinue" for the continue parameter instead of "ucstart". In general, if it is possible to use the existing, documented parameter name, that will cause fewer problems than renaming it. In particular, unless there is a maximum field length to worry about, it seems like it should always be possible to honor the original continuation parameter name for each module. That gives backwards compatibility as long as the client treats the value as opaque data. The documentation that the client should pass the entire query-continue section is very recent [1] and was not at all part of the original document API spec when it was introduced circa 2007. - Carl 1: http://www.mediawiki.org/w/index.php?title=API:Query&diff=603120&ol…

On Sun, Mar 24, 2013 at 11:14 AM, Brad Jorsch <bjorsch(a)wikimedia.org> wrote: Thank you for noticing that. I was thinking of cmstart, which was added as a continuation parameter [1] when cmcontinue had already been established. As you can see, the overall API code is somewhat messy in terms of the parameter names: cmcontinue but rcstart, etc. The continuation system dates back to query.php, which would return a "next" parameter when a query needed to be continued; the value of that parameter was then used to set a specific continuation "from" parameter in order to get the next set of data. In api.php, the values of the "next" parameters were moved to the query-continue section of the response, and the "from" parameters were renamed. I think we agree that the original system was not so well documented. Of course it is a volunteer project - Yuri asked for help with the documentation in 2007, and I was among the people who didn't spend much time helping with that. So the documentation should not be taken as a reflection on Yuri's work at the time to implement things. But if there was never any documentation until 2012 that the entire query-continue section should be passed along (I have been unable to find it), there's no reason to think the existing clients would already be doing it. The only consequence of this is that changes to the names of the continuation parameters for the "old" system should be minimized, and the "new" system should be more clearly documented. - Carl 1: https://www.mediawiki.org/wiki/Special:Code/MediaWiki/33256