In that case - can we sneak this in without deprecation and just do it?
If I understand T232485: RFC: Core REST API namespace and version correctly, the deprecation process for the older parameter values is trivial from a coding standpoint. Shall we hot-add a task for deprecating the old parameters and adding the new ones to the current sprint? That way, as few callers as possible (ideally, none) ever use the old values.
SELECT rev_id,rev_page,rev_timestamp,rev_minor_edit,rev_deleted,rev_len,rev_parent_id,rev_sha1, comment_rev_comment.comment_text AS `rev_comment_text`, comment_rev_comment.comment_data AS `rev_comment_data`, comment_rev_comment.comment_id AS `rev_comment_cid`, actor_rev_user.actor_user AS `rev_user`, actor_rev_user.actor_name AS `rev_user_text`, temp_rev_user.revactor_actor AS `rev_actor` FROM `revision` JOIN `revision_comment_temp` `temp_rev_comment` ON ((temp_rev_comment.revcomment_rev = rev_id)) JOIN `comment` `comment_rev_comment` ON ((comment_rev_comment.comment_id = temp_rev_comment.revcomment_comment_id)) JOIN `revision_actor_temp` `temp_rev_user` ON ((temp_rev_user.revactor_rev = rev_id AND revactor_page = rev_page)) JOIN `actor` `actor_rev_user` ON ((actor_rev_user.actor_id = temp_rev_user.revactor_actor)) WHERE rev_page = ? AND (rev_minor_edit != 0) ORDER BY rev_timestamp DESC, rev_id DESC LIMIT 21;
Looking at this now in engineering task T235587: Add minor edit count to REST API history count endpoint, all the other count types explicitly include "edits":
Tue, Oct 22
The most similar code I found in Action API was this bit in ApiQueryUserContribs.php:
SELECT COUNT(*) FROM `revision` WHERE rev_page = ? AND (rev_minor_edit != 0) LIMIT 1;
Mon, Oct 21
Wed, Oct 16
The number of these messages is likely to grow, perhaps significantly. Splitting them seems like a good idea.
The existing counts for this endpoint do not have unit tests? Should we add a unit test for the new count (and possibly the existing ones)? Or will we cover that with integration tests?
What (if anything) do we need to do with the rev_deleted field in this query?
Body: JSON, object with following fields
minor: total number of minor edits
Tue, Oct 15
It would also be useful to add additional examples, such as how to inject services, use a factory function, etc. Those things would be better done under their own tasks - I mention them here just to bring up the possibility.
Sun, Oct 13
Several of the new Core REST API endpoints accept titles. We should see if they are similarly affected.
Fri, Oct 11
I like consistency. Any renaming we choose to do would be safe, fast, and would not threaten our deadline.
Thu, Oct 10
@Reedy, the OATHAuth and WebAuthn patches look like they're generally on the right track to me and unless that approach proves to be unnecessarily painful, I'd recommend continuing that direction.
Wed, Oct 9
Just speaking for myself, I understand what this task is about conceptually, but I don't know anything about its status or the details of the code. I'm happy to take a closer look if time allows, but I assume my priority is to complete the tasks that I'm the primary coder for.
Tue, Oct 8
@Anomie , discussion arose during our Green Team checking meeting today about 5 endpoints vs 1 endpoint. I know you are tasked with unrelated things right now, but if you have time to give an opinion it would be very helpful.
Mon, Oct 7
So, all slots except "main" go into a slots property that maps the slot name to an object that describes the slot? @daniel any thoughts?
Marking this as "Stalled" because it cannot be done until after the 1.34 release.
Fri, Oct 4
Thu, Oct 3
@eprodromou , could you reconsider splitting the task up? Most of the code is the same between these endpoints - they differ only in the query - so I implemented them using a common base class.
Wed, Oct 2
@eprodromou The associated patch was not merged, so we never did. Unless someone had pulled down that unmerged gerrit change and was using it locally or something, but even then the paths were wrong.
Tue, Oct 1
tl;dr: @eprodromou , what change tags are considered "reverted"? Just mw-undo and mw-rollback, or others too?
Mon, Sep 30
Thank you @Anomie .
Thu, Sep 26
I've created T233963: Add serialization options to RESTBagOStuff and added people who are subscribed here as subscribers to that new task.
So ... I just checked an email from @CCicalese_WMF from about a week ago, and the 1.34 release branch is scheduled to be created on Sept. 29, three days from now. If I need to make changes to RESTBagOStuff before the release, time is growing short.
Wed, Sep 25
For any legacy cases, if they exist
Tue, Sep 24
PHP sessions normally support storing PHP-serializable objects. Breaking that assumption, but only when RESTBagOStuff happens to be being used, seems liable to become a recurring issue which we could easily avoid.
Sep 23 2019
Sep 22 2019
Was this actually announced anywhere that I probably should've seen it?
Sep 20 2019
The first step is picking a name for the extension. The task title says "iOS History API", so I could just make a name out of that. But first, do we:
- foresee non-iOS endpoints being added to this extension?
- foresee non-History endpoints being added to this extension?
This is clearly a breaking change, no argument there. Fortunately, it is a configuration-dependent one and we've only affected ourselves, and in a limited fashion. I'm glad we were as conservative in rolling it out as we were, and I'm suddenly thankful for the the Kask performance investigation (now complete) that delayed further rollout.
I assume that revisions in the response should normally be ordered from newest to oldest (which facilitates looping through them via the paging pseudocode above, which starts at the newest revision and progresses through older revisions). But if newer_than is specified, they should be ordered oldest to newest (which facilitates the inverse direction of looping starting at an older revision and progressing through newer revisions. Am I correct in that assumption?
Sep 17 2019
Also consider T137926 (Support running MediaWiki without 'curl' PHP extension)
Sep 13 2019
Sep 12 2019
@eprodromou is there documentation for what should be returned in various error conditions? The most obvious and likely in this case would be if the revision could not be found, but I'm curious if we have any general conventions about error return values for the REST API.