Most what was told in all the thread was
about 'rewriting' in another languages, but
it totally lacked ideas on how wiki should
be implemented architecture-wise. Right
now, being pushed to LAMP model, we
have several issues. (warning, rants on
crack.. :)
We do use relational data models. They
are quite ok for content website, not great
for massive collaborative editing. In order
to make really large site work we'd either
have to split everything and decrease
funcitonality (no shared watchlists, Timwi :),
or start using some other concepts of scale -
messaging middleware, event brokers, whatever.
With more and more data out there, various
tasks could be moved away. Async aggregated
feeds Though, as we're running on simple 6-disk
dual-opteron db servers we're far from that.
Our current trouble is too much of data on DBs.
With too much of data, more i/o has to be done for
some or another task. This is partially solved by 1.5
mediawiki. Could be solved more by relocating lots of
data to other external stores.
And our current trouble is single media host, though,
it is supported by squids. External storages will help
here as well some day.
I don't really understand what's all that fuss about.
The only real need to rewrite Wikimedia software is to
prepare it for 300+ server infrastructure. Then we'll need
more intelligent solution than single LAMP script-framework.
We need ideas on how to improve architecture of whole
wiki-process, than ideas which language is better and
which language is worse.
With PHP5 we can easy convert our mediawiki into daemons
(HTTP, FastCGI, whatever), that would gain performance.
Sure, we _could_ do same with Python. Sure, Python
has JIT right now, but there are commercial JITs for
PHP out there (which means there will be opensource
some day, Parrot, whatever :)
And sure, there's one more thing that can be done...
Simply replacing Apaches with Lighttpd (
http://www.lighttpd.net/).
We've got great support by lighttpd folks, and have been
running it for our downloads service, and I've been running for
my projects 'at home' with great success. Ah, that could
provide at least 10% (eh, say... 50%).
Domas
P.S. I didn't participate in main discussion as I was away,
and I did later did an intentional break, just to calm everything down :)