I'm replying to this wikipedia-l post in wikitech-l, it's more relevant
here.
Brion Vibber wrote:
> I'd been waiting on Tim's in-progress code to compare. Apparently there's not
> really anything much of that left (his work mostly transmogrified into the
> templatelinks temple) so I'm poking at Magnus's code now.
Salvatore's moderation feature was implemented in a similar way to
Magnus' one, in that it used an extra revision ID field in the page
table to point to the relevant version. Salvatore's used parameters
passed back to Revision to determine whether page_latest or
page_verified should be used, whereas Magnus's code operated mainly at
the UI level, redirecting to a page with an oldid parameter, IIRC.
Neither of them had the structure required for efficient caching, that
is, page/tag retrieval instead of page/revision retrieval. The basic
problem is that tugela, which we are now using instead of memcached, has
no efficient means for identifying and purging expired keys. In fact at
the moment, this garbage collection is not done at all. To limit the
growth of the cache under these circumstances, it's better to index the
parser cache by page and tag, rather than page and revision ID. I
thought that the best way to implement a tag concept, to merge Magnus's
and Salvatore's features while minimising MySQL index space, would be to
put the tag information in its own table.
Then there's the problem of template and link colour changes. I posted
to wikitech-l about that before. Magnus's suggestion of storing the
wikitext with the templates expanded at save time is a quite reasonable
solution.
I stopped working on Salvatore's moderation feature when Brion
implemented the semi-protection proposal put forward by the English
Wikipedia. It was quite redundant -- Salvatore's feature was a form of
semi-protection, a more complicated one than the one that the
Wikipedians were supporting. I was even working on integrating it into
the protection UI when Brion rewrote that part of the code. At that
stage I still hadn't addressed the caching issue. So I salvaged what I
could of my code branch (mostly the templatelinks table), and abandoned
the feature. I wasn't interested enough in the stable version feature to
keep working on the backend.
Perhaps the simplest solution at the moment is to put Magnus's feature
live (after the necessary code cleanup), and put up with the lack of
caching for a while. We've still got a bit of spare hardware capacity
haven't we? The request rate for stable versions should be lower than it
would have been for verified revisions. If I understand it correctly,
stable revisions are not displayed by default, verified revisions would
have been.
-- Tim Starling