I like the idea of porting hotspots, but keep in mind
that we want
people to be able to use this even if they don't have access to a C
compiler.
That's going to be a problem with any non-PHP code, to a greater or
lesser extent, but there's no reason someone can't maintain a (now
modularized) native-PHP parser.
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.
I like this idea, although it carries its own costs. In particular,
communicating between processes has inherent overhead; we'd have to be
reasonably sure that the caching would outweigh that. Also note that
IPC and process-management mechanisms tend to vary across operating
systems; we might lose Windows support, for example.
I'd like to see as much portability maintained as possible, but to be
honest, I'm not personally worried about it. MediaWiki is, first and
foremost, the software that runs the Wikimedia projects. I can't see
us running Windows on the cluster anytime soon.
One advantage of this split is that we could rewrite
one of the
components in another language if we want, without affecting the other
one. If the front end becomes little more than a shell around a
daemon, we could provide a version written in C as an Apache module,
which is about as fast as it gets.
There are numerous options available to us, and that's one of them.
Making MediaWiki the server itself is at the far end of that extreme,
and the are countless possibilities between it and the other.
On the back end, Perl 6 is specced to have one of the
most powerful
pattern-matching engines ever shipped with a language; it should be
able to eat wikicode for breakfast. It's also designed to allow easy
interoperability with other languages, so just the wikicode parser
could be written in it while the rest is left as PHP. Implementation
is moving quickly, with the backend Parrot Grammar Engine in progress
and the Pugs (Perl 6 in Haskell) compiler just starting on the syntax.
(And, of course, you'd have a very happy Perl hacker here.)
I've yet to be sold on Perl 6, but that's just my personal opinion.
It may yet turn out to be the best option, especially if its
pattern-matching capabilities are all the evangelists say they are.
--
Brent 'Dax' Royal-Gordon <brent(a)brentdax.com>
Perl and Parrot hacker
At least you're open about your bias. ;)
-- Austin