Alternate wiki-implementations: Difference between revisions

Revision as of 00:06, 7 November 2003

Currently 3 out of 20 of our registered users are registered MediaWiki developers, which makes our percentage of developers among users 15%, which is likely the highest figure any public MediaWiki installation can boost so that is an good incentive to try to adapt MediaWiki for our use over other wikis. However they might just be here because we are using MediaWiki, so, it is important to make clear that one of the things the R&D Wiki is doing is choosing what technology best fits our hardware requirements later.

There are three leading candidates, and a few dark horses listed afterwards. It seems likely that we'd ask those who want to be Consumerium developers to work on wikitext standards and on soliciting and forwarding end user feedback better, starting with our own MediaWiki modifications requests. Consumerium users should not have to do anything but list these here. Similar pages for TikiWiki modifications and MoinMoin extensions can be created, and which one meets our needs can be more of a competition. In most cases, the features that must be added are different for each package, since they start with different feature sets. Also APC Action Apps might become important to integrate, since they have broad use among nonprofits.

MediaWiki	TikiWiki	MoinMoin
Not humanly possible for end user feedback to reach developers reliably PHP based Proven to perform well under heavy load - but with hard limits Most likely basis for wikitext standard Working now for R&D purposes Dedicated developer community which also mostly develops content Readable documentation, thanks to the above A very high ratio of developers (15% of registered users) registered in consumerium supports MySQL only	Not humanly possible for end user feedback to reach developers at all - form for describing wiki feature request incomprehensible even to a usability guru PHP based meets many standards (CSS, XHTML, pear.php.net, smarty.php.net, RDF email/forums (and integration) built-in Group management built-in chat support intended Visualization of wiki-links Polls built in Many developers doing lots of detail work on CM and CMS supports Postgres, Oracle, Sybase and SQLite (built in PHP 5.0!) databases not just MySQL - strategic to integrate with some essential projects developers eat their own dog food = run current beta as their live site for all development, so any problem is immediately obvious to every developer	End user feedback directly solicited in a public wiki Python language excellent architecture making extensibility very simple easy to write parsers to meet wikitext standard or read MediaWiki or TikiWiki formats troll in the logo no need for any SQL - relies on Unix file system only - fewer glitches, fewer reports (most of which are turned off in the heavy-load wikis anyway)

Dark horses include VeryQuickWiki (a Java wiki), UseMod (only advantage is that it dumps XML output, very very very important until there is a real wikitext standard).

Also Microsoft wiki will likely be out eventually, and some peer2peer options relying perhaps on XForms later. Microsoft Internet Explorer XML Support is an important constraint on which of these features can be used at all. It may be a wise tradeoff to support only MSIE for certain user roles.

See also:

@@ Line 43: / Line 43: @@
 </table>
-Dark horses include [[VeryQuickWiki]] (a [[Java wiki]]), [[UseMod]] (only advantage is that it dumps [[XML output]], very very very important until there is a real [[wikitext standard]]).  Also [[Microsoft wiki]] will likely be out eventually, and some [[peer2peer]] options relying perhaps on [[XForms]] later.
+Dark horses include [[VeryQuickWiki]] (a [[Java wiki]]), [[UseMod]] (only advantage is that it dumps [[XML output]], very very very important until there is a real [[wikitext standard]]).
+Also [[Microsoft wiki]] will likely be out eventually, and some [[peer2peer]] options relying perhaps on [[XForms]] later.  [[Microsoft Internet Explorer XML Support]] is an important constraint on which of these features can be used at all.  It may be a wise tradeoff to support only MSIE for certain [[user role]]s.
 ----