The service stacks that support mobile (web/Android/iOS) need to support multi-content revisions (see especially the use cases there for background). This is an exploratory task to figure out the shape of that.
In the current PHP stack, some storage service looks up the content and metadata for the current revision, the content handler generates a HTML blob from it (in the case of wikitext this involves the parser and extension callbacks), the skin takes the content HTML and the revision metadata and renders the final page. For mobile, that is replaced by client-side rendering: the app fetches the revision metadata (via the PHP API or RESTBase/MCS), it fetches the content blob (via Parsoid/RESTBase/MCS, or by calling the PHP parser via the MobileFrontend API), and renders the final page.
In the new post-MCR PHP stack there will be more steps: the storage service looks up the revision metadata, and the slot metadata and content for each revision slot, the content handlers generate a HTML blob from each slot content, these slots get combined into a single HTML blob, and that gets handed along with revision metadata to the skin. So there will be a step that's largely analogous to the old rendering process (slot content -> slot HTML) and a new "combining" step (multiple pieces of slot HTML -> single multi-content HTML). Alternative renderings that don't use MediaWiki skin (and possibly parsing) logic will need to reproduce this.
(Note that there is significant uncertainty at this point around the "combining" step - it might pretty much just concatenation, or it might be more complex. It might be some transformation starting with a set of fully rendered slot HTMLs, or it might be more integrated with the parsing process.)
Specifically, this probably means that
- Parsoid needs to be able to address single slots (i.e. handle routes like /page/html/<title>/<slot> and /page/html/<title>/<revision>/<slot>) and handle invalidation correctly (slots can depend on other slots of the same revision)
- something (probably MCS?) in the Node stack needs to be able to combine a bunch of slot HTMLs into a single HTML so that apps can show a single-page rendering of any content they don't have any special handling for. This is probably going to be fairly simple (just wrap them in some HTML container and concatenate).
- in RESTBase, /page/html/<title> and /page/html/<title>/<revision> should maybe redirect to that combining service. (Or maybe it should only show the main slot - not clear which would be the more sensible behavior for old clients.)
- apps that use core MediaWiki API calls will have to implement HTML combining on their side, or the APIs might take care of that themselves when no slot parameter is present. I don't think there is any major app still using such calls.
- for apps that use MobileFrontend's mobileview API, that API needs to do the HTML combining (there will be a PHP service for that).