Given that EditPage is undergoing massive refactoring, are we not going to be writing code to immediately through it away soon?

In T239743#5716752, @eprodromou wrote:

@Pchelolo but we can rely on a library in core, right? Could we just depend on the Parsoid/PHP library, not the Parsoid/PHP MW extension?

We can't rely on Parsoid while it's an extension from within core, so this logic will go into the extension now ad will be moved over when Parsoid is not an extension anymore.

Ummmmm... duh. Should we change this to user name instead? It's mostly for segmenting the list, rather than clients caring that much. The order of editors is arbitrary and up to the implementation.

In T239843#5716441, @eprodromou wrote:

@WDoranWMF I wonder if we could get data from analytics about this?

A couple more questions I have after digging a bit into the parsoid php code, I have a bunch more questions:

These contributors should only be users who've made edits on the shortest path in the edit history.

Yeah, that's why the definition was changed to

In T238374#5710638, @WDoranWMF wrote:

@Pchelolo Thank you for writing this up. I would agree with initially going with 1 minute as the default for now. But I'm curious how can we track and tune it long term? Is there data captured on what "normal" is?

We haven't been using scoped packages in the past because Debian Jessie npm version was too old to support them, but nowadays that's not a problem anymore

There was some misunderstanding about what 'cache-control' role in here.

Depending on the target performance. I think it will perform pretty well as is. Purging this cache will not be very complicated, but I doubt the benefit/complexity ratio

Yeah :) We can probably add some staleness for the client-side caching. As for revalidation headers - I don't see a way to do it more efficient then reloading the whole response. Can do that to save up a bit on data transfer.

This is a "MUST", so we really don't have a lot of options.

contributors: array of User objects for the contributors to the page, each with these properties
id: user ID
name: user name

Also important is making sure we flush the Varnish cache when an object is edited, deleted, or undeleted.

A couple more thoughts:

I guess we eventually would want to get rid of this?

There was a lot of resistance to the idea of having an endpoint for OpenAPI 3.0 definitions of the (other) endpoints.

https://github.com/zircote/swagger-php is a tool worths looking at.

Seems like after the last deploy the jobs are being partitioned according to the cluster correctly.

Done.

DISCLAIMER: I assume that the .partitioned. name was discussed and decided, don't want to get into the naming bikeshedding in here :D

I believe these should do it?

Ok, I can live with the coredev thing.

It's still a viable idea, but I don't think we have the capacity to work on it now. Icebox.

Given that we're planning to get rid of JS parsoid and RESTBase, I'm declining this.

Given that there's an idea to move reading lists rest api into PHP, I'm declining this.

This is still a viable idea, but I don't think we have the capacity to work on it right now. Maybe after migrating to prometheus.

Nothing to do here for the core platform team anymore.

Given that there's been no activity since 2017, I'll close this.

Graphoid is likely going away, so we shouldn't work on this.

the idea is still solid, but I don't think there's a pressing need to do it now.

I will verify if it's still the case

I've created individual tickets for the services still not addressed. Closing this umbrella ticket.

The if-unmodified-since in RESTBase is used for an optimization, but it almost never kicks in for external requests, mostly it's relevant for change-prop. So I think we can just remove this header from the client request

No surprise. @jijiki has deployed 1.10 to labs machines as indicated in the parent task, but not yet on prod machines, pending verification that it works correctly in labs.

Hehe... @jijiki could you do deployment-parsoid as well please?

The core REST API is already a part of MediaWiki core and MW has it's own versioning scheme. Introducing one more version will create a lot of confusion. Installing MW LTS release v1.xx - which core REST API minor version do I get? Where do I look it up? What does the semantic REST API version give me? Can I install a specific version on top of a different MW release? All of these are rithorical questions for the purpose of the ticket. TLDR: If core REST was implemented as an extension, this could make sense. Since it's a part of the core, it should follow the core versioning scheme.

This is hitting the revision limit that was specified in the task when we implemented it. So it's a feature not a bug.

It's implemented in the mobile-content-service. https://gerrit.wikimedia.org/r/admin/projects/mediawiki/services/mobileapps

Because the distinction is made in our Web UI. It's a user-level abstraction, and we should support both.

Seems to be a duplicate of T236320

One more thing to consider after reading the documentation https://en.wikipedia.org/wiki/Help:Reverting#Undo - it seems like undo on MW has a bit of a different process then revert - a contributor is presented with a diff to review before committing the action. In both of the proposed endpoints there's no way of following the same process for undoing - the compare endpoint wouldn't be able to provide a diff like that. So, if we DO want to support the same process as the core, we need additional endpoints.

The patch above adds minor flag to both /revision/{id}/bare and /page/{title}/history endpoints.

I'd really like the GET and PUT URLs to be the same.

200 – this is the page
404 – revision does not exist (never created or deleted)

There's 100.000 resource_change events here https://people.wikimedia.org/~ppchelko/resource_change_events

In T221167#5642481, @Anomie wrote:

There's no HTTP standard for gzipped request bodies, as far as I know. Is there a standard?

I have posted the first round of comments about this story in the undo story T237577#5645099cause they are very similar. I have more comments about this one, but we first need to go through the first round, that might make the rest of the comments not relevant.

This endpoint is quite similar to rollback endpoint T235072 and a lot of comments/questions/ideas would apply to both or are cross-cutting between them, so I will comment once here, but please be aware that it mostly applies to both.

The patch was merged. Nothing to do here, making an integration test to check that 1001 revisions are not queried doesn't seem feasible.

Updated the patch to set the limit to 1000.

Should we consider deprecating sending non-json input?

yeah, I understand. I mean, once in eventuate you have the map, you'd need pretty much the same code as you'd need in the stream config extension to map the actual stream name to the config. Thus, loosing the array ordering will make it possibly inconsistent

I know reading infrastructure were using https://en.wikipedia.org/wiki/User:BSitzmann_(WMF)/MCS/Test/Frankenstein as a page with a lot of different weird characteristics.

mmm... if we convert the array into a key-value map, we loose the ordering of the array. Thus, we can't do that thing when stream matching works for the first match in the array.

It's "almost" standard https://www.mediawiki.org/wiki/Manual:Language#Language_code