I've been perusing some of the FlaggedRevs code recently (as it has evolved). It
seems to be heading in a good direction. I'm not sure what ideas have been rumbling
around in all your heads, but I thought I'd share the following thought with you in
case it hasn't been brought up yet.
Performance is likely to be something of an issue, and will become more so as the database
becomes populated with growing numbers of flagged revisions. Obviously the most common
operation is to display the default version of an article. With FlaggedRevs this involves
joining rows from the flaggedrevtags, flaggedrevs, and revision tables in a nontrivial
database operation. The idea is to mostly avoid this with an additional table.
The table in its simplest form would just have two or three columns:
PageID (primary key)
RevID of the "latest stable revision" by namespace criteria
Valid flag for above RevID (or coded by NULL in revid, etc)
A default-revision access would go directly to this table and if a valid revid is found
would then pick up the text of the page from the flaggedrevs table. If not found, the
access would proceed as in the current approach. Possibly the access itself should put
the resulting revid into the above shortcut table, but maybe this update would be done by
a background task, or just by review-updates.
Once filled in, the default-revision access should be much better, even for only
occasionally-accessed pages. Having this table requires that an update to the revid or
valid flag be done when a page is given a new review setting, so that the new shortcut
table will not persistently yield a wrong answer.
Now, all that seems good, but this table also should help with support of the number one
wishlist item, per-page default-selection criteria. The shortcut table could record the
criteria to be used for the page, perhaps in a text form convertable to the
$wgFlaggedRevTags PHP variable which controls the selection.
With that in the table, a default-revision access would again use the revision found if it
is set, otherwise select the revision using the page-specific criteria if they are present
(otherwise the namespace default, of course). The table would also then be used in the
other various flagged-revision queries, since it would be the residence of the per-page
revision selection criteria.
I'd guess this idea has no particular implications for the early implementation now
advancing rapidly, but it might be useful to ponder for work a bit down the road.
-RS