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
