Alternate wiki-implementations: Difference between revisions
No edit summary |
No edit summary |
||
| Line 37: | Line 37: | ||
*[[End user feedback]] directly solicited in a public wiki | *[[End user feedback]] directly solicited in a public wiki | ||
*Python language | *Python language | ||
*excellent architecture making extensibility very simple | *excellent architecture making extensibility very simple - [[Market Model]] separating [[ActionMarket]], [[ProcessorMarket]], [[SkinMarket]] and [[ParserMarket]] - each of which runs in strict [[Request and Offer form]]. | ||
*easy to write parsers to meet [[wikitext standard]] or read [[MediaWiki]] or [[TikiWiki]] formats | *thanks to [[ParserMarket]], it's easy to write parsers to meet [[wikitext standard]] or read [[MediaWiki]] or [[TikiWiki]] formats | ||
*no mindless/wrong [[virtual community]] rhetoric to cause misfeatures - just a good tool | |||
*[[troll]] in the logo | *[[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) | *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) | ||
Revision as of 00:29, 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. One might for instance be written to support some common barcode readers, in cooperation with Adbusters or another of the essential projects which recognizes barcodes as being as critical as we think they are. Maximum cooperation and out-sourcing should be encouraged.
| MediaWiki | TikiWiki | MoinMoin |
|---|---|---|
|
|
|
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, if these are always taken on by well-equipped well-supported people who can be far more easily supported by relying on IE's XML, than any other method. By the same argument, if Opera or Netscape does something uniquely well and only two or three people need that capability, requiring those might also make sense for some roles. For ordinary end users the APC Action Apps baseline browser capabilities should probably be adopted as Consumerium's own.
See also: