|
|
| (4 intermediate revisions by the same user not shown) |
| Line 1: |
Line 1: |
| − | == Warum habe ich TWiki ausgewählt ==
| + | Has been moved to: http://blog.kr8.de/wiki-wikiwikiweb-auswahlverfahren/ |
| − | | |
| − | === Meine Anforderungen ===
| |
| − | Ich habe die Idee, ein [[WikiWikiWeb]] für die Speicherung aller meiner Notizen, Zettel, Hobbies usw. einzusetzten. Dazu muss es ganz einfach zu handhaben sein (statt Zettelschreiben, schnell ins Wiki eingeben, ohne Technologie-Schwellen-Barriere). '''Soll so einfach sein, wie das Schreiben von E-Mails.''' Stichwort: elektronischer Zettelstapel auch als eine Art ''Knowledge Management'' für private und auch berufliche Zwecke.
| |
| − | | |
| − | Ich möchte die Sachen leicht wiederfinden können, d.h. [[Volltextsuche]] und Kategorisierung ist wichtig. Die so gespeicherten Informationen müssen dort sicher aufgehoben sein. Ein Datenverlust muss ausgeschlossen sein. Die Inhalte werden langfristig (> 10 Jahre) genutzt und müssen prinzipiell in neu aufkommende Systeme migrierbar sein.
| |
| − | | |
| − | Der Übergang von einem Computer auf einen anderen (Nachfolger oder parallel) und die Veröffentlichung zum Web-Provider soll leicht möglich sein.
| |
| − | | |
| − | Es soll sich in die bei mir vorhandene IT mit geringstem Zusatzaufwand möglichst nahtlos einfügen.
| |
| − | | |
| − | === Meine [[Anwendungskatalog|IT-Architektur]] ===
| |
| − | * Betriebssystem: (1) Windows, (2) Linux
| |
| − | * Webserver: (1) [[Apache|Apache]],...
| |
| − | * Scriptsprache: (1) [[PHP|PHP]], (2) [[Perl|Perl]]
| |
| − | * [[Datenbanken|Datenbanken]]: (1) [[MySQL]], (2) [[MicrosoftAccess]], (3) dBase
| |
| − | | |
| − | === Meine Bewertungskriterien ===
| |
| − | * Zukunftssicherheit
| |
| − | * Stabilität und Fehlerfreiheit
| |
| − | * Export-/Import-Schnittstelle (Datensicherung und Datenaustausch)
| |
| − | * Funktionalität (Volltextsuche,...)
| |
| − | * Konformität mit meiner IT-Architektur (s.o.)
| |
| − | * Betreibbar bei einem meiner WebProvider-Provider
| |
| − | * Dokumentation und Support
| |
| − | | |
| − | === Meine Shortlist ===
| |
| − | * PhpWiki
| |
| − | * [[MediaWiki]]
| |
| − | * UseModWiki
| |
| − | * TikiWiki
| |
| − | * [[TWiki]]
| |
| − | * JSPWiki
| |
| − | | |
| − | === Nicht auf die Shortlist kam ===
| |
| − | * pmwiki, da es eine zu kleine Community hat. Sieht aber sehr gut aus und ist eine reine PHP-Lösung (ohne SQL). http://www.pmichaud.com/wiki/Main/HomePage
| |
| − | * MoinMoin, weil es mit Python statt PHP für mich zu exotisch war. (Allerdings sher interessant, weil es ohne [[RCS|RCS]]/[[CVS|CVS]]/[[MySQL|MySQL]] auskommt und weil die Jakarta/Apache Community es als ihr Wiki http://wiki.apache.org/jakarta/ ausgeählt hat.)
| |
| − | * cowiki, weil es noch zu neu ist und PHP5 benutzt: http://www.develnet.org
| |
| − | * DocBook Wiki, weil ich es noch nicht kannte (http://sourceforge.net/projects/doc-book/)
| |
| − | | |
| − | === Meine Kurzbewertung ===
| |
| − | Für '''PhpWiki''' sprach die Konformität mit meiner IT-Archtektur (PHP und MySQL). Gegen PhpWiki sprach letztlich die '''Instabilität''' und die '''kleine Community/Präsenz''' (kleines Entwicklerteam, wenig Dokumentation und Support, wenig Websites mit PhpWiki).
| |
| − | | |
| − | Für '''MediaWiki''' spricht die hohe Stabilität und Reife, die sich darin zeigt, dass die Wikipedia mit MediaWiki gemacht ist. Gegen MediaWiki sprach die höhere Komplexität und die Tatsache, dass MediaWiki ausser für mehrere Wikipedias ansonsten kaum von anderen grösseren Wiki-Sites eingesetzt wird. Die fehlende Import-/Export-Schnittstelle war ebenfalls ein Minuspunkt.
| |
| − | | |
| − | Für '''UseModWiki''' (http://www.usemod.com/cgi-bin/wiki.pl) sprach die gute Stabilität und Community/Präsenz, die sich darin zeigt, dass auf Basis von UseModWiki mehrere grosse Wikis betrieben werden z.B. [[http://www.usemod.com/cgi-bin/mb.pl Meatballwiki|http://www.usemod.com/cgi-bin/mb.pl Meatballwiki]]. Ein Minuspunkt aus meiner Sicht ist die nicht so gute Konformität mit meiner IT-Architektur ([[Perl|Perl]] statt [[PHP|PHP]]). Gegen UseModWiki sprach letzlich der relativ schlichte Funktionsumfang; z.B. gibt es keine gute Export-/Import-Schnittstelle.
| |
| − | | |
| − | '''JSPWiki''' (http://www.jspwiki.org) habe ich im März 2005 bei einem grossen Anwender in der Schweiz kennengelernt. Vorteile sind: Kommt ohne [[RCS|RCS]]/[[CVS|CVS]]/[[MySQL|MySQL]] aus. Kommt ohne Perl aus, wofür dann JSP erstmals in meine Architektur käme - was aber sicher als fällige Weiterentwicklung in die [[Java|Java]]-Welt positiv gesehen werden kann. Die Frage ist, ob ich WebProvider-Provider finde, die JSP unterstützen.
| |
| − | | |
| − | Für [[TWiki|TWiki]] sprach die hohe Stabilität und gute Community/Präsenz (inkl. Dokumentation und TWiki:Support ), die sich in der grossen Verbreitung von TWiki als Basis von öffenlichen und firmen-internen Websites zeigt siehe: TWiki:Main.TWikiSuccessStories <br />
| |
| − | Bestechend ist die sehr reichhaltige Funktionalität. Gegen Twiki sprach die nicht gute Konformität mit meiner IT-Architektur wegen [[Perl|Perl]] (statt [[PHP|PHP]]) und [[RCS|RCS]] als Datenhaltungssystem statt MySQL. Mit Perl konnte ich mich angesichts der Tatsache, dass mein WebProvider-Provider es unterstützt und es als zweite Wahl in meiner IT-Architektur gesetzt ist, schon anfreunden. [[RCS|RCS]] als Datenhaltung für das Wiki schien auf den ersten Blick recht merkwürdig, war aber bei näherer Betrachtung durchaus akzeptabel, denn [[RCS|RCS]] ist klassischer UNIX-Bestandteil und auf allen Plattformen ([[Cygwin|Cygwin]]) verfügbar. Gegenüber einer Datenbanklösung (z.B. MySQL) ist [[RCS|RCS]] leichtgewichtiger und löst auch das für mich ganz wichtige Probelm einer Export-/Import-Schnittstelle - zwar nicht ganz so wie eigentlich gedacht, aber die Basisfunktionalität Export/Import ist da.
| |
| − | | |
| − | | |
| − | -- Main.DietrichKracht - 31 Dec 20033
| |
