Last modified: 2014-10-24 15:05:30 UTC
The API shows the warning about missing continuation parameters even when it is inappropriate. Many false positive warnings will hide the warnings that are really relevant. There are two groups of false positives: 1. Queries that just can't be continued: http://en.wikipedia.beta.wmflabs.org/w/api.php?action=query&meta=tokens&format=jsonfm Why should I add a continuation parameter for a simple query to get a token? Just don't show a warning for meta submodules (I think these are the only that can't be continued). 2. Queries that could be continued, but won't be continued: http://en.wikipedia.beta.wmflabs.org/w/api.php?action=query&prop=revisions&format=jsonfm&rvlimit=1&titles=Main%20Page I am interested in the latest revision only, otherwise I wouldn't have set the limit to 1, so the warning is useless for me. I can think of three different solutions for this group: 1. Don't show a warning for queries with an explicit limit=1, as these are the queries that the user most likely doesn't want to continue. 2. Don't set the warning directly, but add a parameter to the continuation data, i.e. return "query-continue": { "revisions": { "rvcontinue": 115406, "showwarning": "" } } When the client continues the query, he should add all parameters from the continuation data, so he will include the showwarning parameter in the next query, which can be used to show the warning in the second answer. 3. Provide a nocontinue parameter, which can be used by the client to suppress both the warning and the continuation data.
(In reply to Michael M. from comment #0) > Just don't show a warning for meta submodules (I think these are the only > that can't be continued). meta=allmessages might return continuation (using amfrom), if the combined text of all the messages being returned exceeds $wgAPIMaxResultSize. If all the requested values for siprop don't fit, meta=siteinfo might return 'siprop' as a continuation. > 1. Don't show a warning for queries with an explicit limit=1, as these are > the queries that the user most likely doesn't want to continue. I'm not so sure about that. In bot code I've written, there are cases where I use limit=1 because I don't want to fetch a lot of unnecessary data when I expect that 99% of the time the first result will be what I need but where I do continue if necessary. And someone who has to pay per megabyte may do that more often than I do. > 2. Don't set the warning directly, but add a parameter to the continuation > data, i.e. return > > "query-continue": { > "revisions": { > "rvcontinue": 115406, > "showwarning": "" > } > } > When the client continues the query, he should add all parameters from the > continuation data, so he will include the showwarning parameter in the next > query, which can be used to show the warning in the second answer. OTOH, that doesn't show the warning on the original query. > 3. Provide a nocontinue parameter, which can be used by the client to > suppress both the warning and the continuation data. If the client wants to suppress the warning, they should use the "continue" or "rawcontinue" parameters and just ignore the continuation data.
(In reply to Brad Jorsch from comment #1) > meta=allmessages might return continuation (using amfrom), if the combined text > of all the messages being returned exceeds $wgAPIMaxResultSize. > > If all the requested values for siprop don't fit, meta=siteinfo might return > 'siprop' as a continuation. Well, then all meta submodules except these. Or (if you think there could be extensions that add other meta submodules using continue) use a whitelist for the modules that should not trigger a warning. It just doesn't make any sense for meta=tokens and similar. > If the client wants to suppress the warning, they should use the "continue" > or "rawcontinue" parameters and just ignore the continuation data. I find it a bit odd to explicitly request a specific continuation format if I'm not interested at all in the continuation data. Once the default is switched the parameter won't serve any purpose in that query, so it will just make maintenance a bit harder. Using a parameter that is meant to specify the continuation format to just suppress a temporary warning seems misuse to me.
Please allow a client to fetch siteinfo siprop=general field generator (version) without version specific behaviour! It should _never_ appear in the second response chunk (for a request of only 'general') unless the sysadmin has misconfigured their server, very badly. Having to add 'continue' (v1.21+) to the request, or 'rawcontinue' (1.24+?) , in order to avoid a warning in 1.25 and an error proposed for 1.26 isnt nice. Older generators return an error (no data) if there is a request parameter that it doesnt understand, so we cant blindly add 'continue' to a request for the generator version. This wouldnt be so much of an issue, if the warning was machine readable, as it could be ignored if the generator is 1.25ish. But it is not machine readable. It is just a chunk of random English words, not even using the keyword 'deprecated'. https://www.mediawiki.org/wiki/Thread:Talk:Requests_for_comment/API_roadmap/Deprecation_codes
