Page MenuHomePhabricator

FlaggedRevs for Mobile Content Service
Closed, DuplicatePublic

Description

Let's discuss how we will handle FlaggedRevs from a MCS and RESTBase point of view.

This probably has implications for RESTBase storage planning and ChangeProp.

Links

https://en.wikipedia.org/wiki/Wikipedia:Flagged_revisions#Projects_that_apply_FlaggedRevs

Event Timeline

Hm.. This might be very problematic to support both for RESTBase and ChangeProp. Here's a list of issues that pop immediately:

  1. Although RESTBase allows access to a specific article revision for mobile content, only latest revisions are actually stored, and previous revisions will be generated on the fly dramatically increasing latency.
  2. The FlaggedRevs extension docs say that "these revisions will remain the same even if included templates are changed or images are overwritten" - so for the flagged revs we have to switch off normal change-propagation, transcludes rerenders etc.

One idea how to achieve that is to create a new event revision-approved, switch off normal mobile content updating for wikis with FlaggedRevs extension and instead only generate mobile revisions in reaction to that event. In that case the 'latest' mobile revision will actually be the 'latest approved' revision, so normal views will see the approved version. Downside of this approach is the need to create an event that's dependent on the extension, and the need to keep the list of wikis that have the extension installed, but it seems like the simplest solution.

We should see if we can somehow accommodate 1) in our storage planning. It seems tricky, but not necessarily impossible. For example, we could consider a second copy of the data table that stores flagged revisions *if they differ from the latest revision*.

I'm not sure how critical 2) is in practice. I doubt that linked content like images actually stays the same, as those are identified by name, updated in the CDN, and might be used in other pages as well.

"these revisions will remain the same even if included templates are changed or images are overwritten" - so for the flagged revs we have to switch off normal change-propagation, transcludes rerenders etc.

I read this differently but I'm not sure which one is correct. I think this still allows for template transclusions and image updates to occur. My interpretations is that the revision number stays the same even if there is a transclusion or an image update, which is true regardless of FlaggedRevs. If someone knows better please chime in. I don't have a lot of experience with FlaggedRevs yet.

The code captures versions of dependencies, so I think there is *some* level of stabilization. However, given the non-deterministic nature of transclusions, newer features like Lua, and non-stabilized components like extensions, I would expect coverage to be less than complete.