There are a couple possibilities here. One is to rewrite MediaWiki in some other language entirely, say Python or C# or whathaveyou.
This is obviously the most difficult and problematic, but could perhaps be a target for 3.0 (or even 4.0).
The other is to keep refactoring the PHP codebase (and it's been much changed since you left it, Lee) and, optionally, rewrite particular hotspots in another language.
This would be a minimum, I think. I'd like to see what the Flex parser gives us, although I suspect an OCaml implementation may be able to do one better.
A possible middle road is to rewrite the core wiki engine to a separate daemon, and adapt the existing PHP user interface to call into it for much of the backend work that actually touches data.
Any external parser may need to be daemonized anyway for speed, even taking OS-level binary caching into consideration. Breaking out the database engine with it offers the possibility of a more flexible database solution, although that may be best handled as part of the object store project.
If there's a really strong reason for a rewrite, then we should start planning a (cleanly implemented, *compatible*, complete) rewrite, making use of the existing parser tests and other tests in existence and yet to be written to make sure it'll really be able to take over. If we do, we should probably target the end of this year or early next year for taking it live. (No need to rush though; if we're going to rewrite, the point is to plan ahead and do it right.)
I'm not totally convinced that there is a really strong reason, though.
Making it a goal now ensures that we *can* take our time "doing it right," *before* it becomes an immediate need. A comprehensive test suite is a must for this, and I know a lot of work has been put into improving the one we have over the past few weeks. And, of course, there's still room for optimization in the current codebase.
-- brion vibber (brion @ pobox.com)