![[Home]](http://meatballwiki.org/meatball.gif)
RewriteMediawikiInJava
MeatballWiki | RecentChanges | Random Page | Indices | CategoriesIt's time to rewrite MediaWiki in Java. Java offers a pretty much debugged and standard VM that'll run on everything from a JavaPhone? to your old MegaBox? to today's GigaBox?. There's no competing language that has the same degree of multi-vendor support for RelationalDatabase? and even DurableTwoPhaseCommit? - which wiki eventually has to support (this EditConflict stuff just can't be the only way to do things!).
While it is also potentially possible to RewriteMediawikiInC?++, it's more difficult since C++ has no VM and needs to be rewritten for each platform. The performance edge of writing in C++ is much narrowing, and Java's transactional capabilities are a far better match for the problems of CollaborativeEditing?.
A FreeSoftware rewrite under GNUPublicLicense? (same as the current MediaWiki) should also allow a lot of programmers to work on MediaWikiExtension? projects, and there are more Java than C++ programmers. While there are also a lot of [LAMP] programmers, the complexity and poor documentation and rapid evolution of the existing unarchitected mediawiki software means that only a very few of those can contribute to code.
Attempts to define a more IdealWiki (such as http://meta.wikimedia.org/w/index.php?title=MediaWiki_Ideal ) emphasize a lot of goals that will be very hard to achieve without some features copied from other wikis:
- a flexible data storage layer like TikiWiki, which would allow MySQL? to be replaced by PostgreSQL? or DB2Express (which IBM is now heavily supporting for use on collaborative web problems, and is very robust)
- a flexible parser like MoinMoin, which would allow for extensions to the standard MediaWiki parsing engine to be managed properly, and ideally flagged when incompatibilities to the current format arises - WikiMarkupStandardIsMisguided and it's quite irrational to expect mediawiki format to ever be replaced. The sheer number of articles prevents it
- TWiki ReflexiveWiki? features that make it easy to change the wiki from within the wiki - very important
Also many IncompatibleEnterpriseWiki? (a WorseProblemSoldAsSolution? ) projects have some useful ideas, and as these MeTooProduct? offerings are righteously wiped out as YetAnotherIncompatibleWiki?, there will be more and more users abandoned who will look for the most flexible base that gives them access to the vast GFDLCorpus and CreativeCommons CommonContent (the main reason why mediawiki can never be fully displaced).
The actual project to rewrite mediawiki in Java should probably proceed in steps (edit freely, this is a collaboration):
- create a database layer in PHP, copying tikiwiki's, so that it becomes easy to store mediawiki data in a robust database, and move it around to other code bases relying on PostgreSQL? or DB2Express for experiments
- create a parser layer in Java, copying the MoinMoinParser? interface (which is in Python, easy for good coders to translate), and provide the tools to ConvertMediawikiToXHTML? - this won't work but many people are trying it, and if they start using the forked code base that will be cloned into Java, the odds that they'll continue to use that code base and focus on the rewrite when they give up on XHTML conversion is increased; Also the people still using WikiWord nonsense can start to write parsers to escape that trap
- meanwhile the PHP programmers can catalogue the MediawikiExtension? list ( http://meta.wikimedia.org/wiki/Category:MediaWiki_extensions ) to figure out where the most used hooks are, especially to the database; meanwhile the Java programmers can try to extend the Java parser to invoke the extensions that affect the markup; Find specific applications and groups willing to adopt the Java version if their extensions are supported - focus on those
- clone the MediaWikiGUI? in Java with [its most annoying problems] fixed, in particular using slightly less verbose and ambiguous terms, avoiding MixedMetaphor?, and fitting on the VerySmallScreen? - this will bring in the MobileWiki? users, who are presently using incompatible badwiki. Graft this Java interface onto the Java parser (easy) and then code direct support for one of the databases, preferably not MySQL?, so that those migrating off MySQL? will adopt the Java code naturally
- clone the database layer into Java so that MySQL? users can keep using MySQL?
Some effort to keep defining an IdealWiki would also help to bring in people whose needs aren't met by the current LAMP mess. Supporting emerging standards like OpenID and possibly gACL would bring in the specific groups that need these things.