Open Source Diva named CTO Options

[anthony]

So who is this Danese Cooper? I see that David Gerard created her BLP in 2005. On that point alone I'm skeptical.

[Zoloft]

Ultimately, if MediaWiki fails to move away from PHP, this by itself could be what kills Wikipedia.

[Kelly Martin]

Ultimately, if MediaWiki fails to move away from PHP, this by itself could be what kills Wikipedia.

Jimmy Wales, and by extension Wikimedia, is far too conservative to "gamble" on a platform change at this late stage of the game. In Wikipedia's ten years there has been almost no functional or technical change in the Wikipedia platform. Contrast Facebook, whose current platform bears absolutely no technical resemblance and fairly little functional resemblance to what it was like when it premiered.

[Zoloft]

Ultimately, if MediaWiki fails to move away from PHP, this by itself could be what kills Wikipedia.

Jimmy Wales, and by extension Wikimedia, is far too conservative to "gamble" on a platform change at this late stage of the game. In Wikipedia's ten years there has been almost no functional or technical change in the Wikipedia platform. Contrast Facebook, whose current platform bears absolutely no technical resemblance and fairly little functional resemblance to what it was like when it premiered.

In agreeing with you, I will differ to this extent; the WMF has enough cash to parallel-develop MediaWiki 2.0 while maintaining the 1.x line, then bringing up servers with the newer, faster, more scalable version and importing the database and links.

Properly managed, very low risk, really high upside.

I'm lazy enough to assume without even looking that no such development is actually planned.

[Somey]

Properly managed, very low risk, really high upside.

Ehh, it's that "properly managed" part that seems to be the real sticking point...

I myself am sort of a programmer... It's an interesting question, to me, anyway, what programming language/platform they'd use if they rebuilt MediaWiki from the ground up to take advantage of the "latest technology." I know J2EE isn't bad, but they could do better than that, couldn't they? And isn't it the database (MySQL) that causes the real bottlenecks, as opposed to PHP, or is it the fact that they use both, or that they use an interpreted server-side language in the first place?

[Kelly Martin]

I know J2EE isn't bad, but they could do better than that, couldn't they? And isn't it the database (MySQL) that causes the real bottlenecks, as opposed to PHP, or is it the fact that they use both, or that they use an interpreted server-side language in the first place?

Given that MediaWiki doesn't have any real need for a fully ACID compliant database, there is no good reason not to use something like HBase (which is what Facebook uses) for the database. The other big performance win would be to rewrite the parser; right now it's a crazy mess of regular expression abuse combined with an XML parser that ends up being expensive in both time and space. Recoding it using either traditional or more modern parsing techniques would likely be a big win on multiple fronts; however, doing so would likely require making some small changes to the markup language. MediaWiki markup is definitely not in LL(n) for any n, and I think it's also not in LR(n) for any n; also, the parser currently requires database access, as the correct parsing of some constructs is dependent on database content. Making a few minor changes to the language "specification" (there really isn't one, just a reference implementation) would avoid both of these problems and make writing a proper parser much easier (that is, possible), but there is considerable reticence to making any change that would "break" Wikipedia.