"As a MediaWiki Developer, I want to get, set and delete the parser output metadata in the parser cache, so that I can return it later to clients that use it."
This is specifically for Parsoid; it has two blobs of JSON that need to be cached separately from the HTML output.
It is OK for the metadata blobs to fall out of cache out of sync with the HTML output (I think; @cscott can you confirm?).
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Stalled | None | T324931 Clean up open RESTBase related tickets | |||
| Open | None | T262315 <CORE TECHNOLOGY> API Migration & RESTBase Sunset | |||
| Resolved | MSantos | T264669 Move VE API from RESTBase into core. | |||
| Invalid | None | T262572 Use Parsoid-specific Parser Cache for Visual Editor | |||
| Duplicate | None | T262586 MediaWiki Developer stores parse metadata in parser cache |
It is OK for the metadata blobs to fall out of cache out of sync with the HTML output
If a client makes disconnected requests to a HTML blob and their associated data-parsoid & data-mw blob, and some blobs have fallen out, you will cause the client request to fail.
So, unless you mandate a client request flow where clients force blobs to be stashed when making their first request for any of the blobs (for example, RESTBase requires this for any client HTML request where they anticipate saving that HTML back after edit), this will cause a lot of client failures.
Unlike RESTBase's stashing mechanism which is used only on edit requests, data-mw blob requests will likely be a lot more common. So, all those requests will now need to add a new parameter and you will need to figure out how to pin the blobs together.
So, overall it seems simpler implementation and client-request-wise and also fewer bugs potentially for the blobs to be fall out of cache in sync rather than out of sync.