Die Idee der SVNwiki soll mein Problem einer idealen Wiki für das technikum29.de-Projekt lösen. Die Vorraussetzungen, die unter anderem in meinem Artikel technikum29.de Versionszählung zusammengefasst werden, konnten mir keine verbreiteten Wikis erfüllen (vgl. WikiMatrix: Wikis mit RCS-Anbindung).

Eckpfeiler der SVNwiki

SVNwiki versteht sich als ein Frontend für SVN, welches SVN um Wiki-Fähigkeiten erweitert. Damit geht es genau den umgekehrten Weg zu vielen Wikis, die Revisionskontrollsysteme nur als eine Art der Speicherung nutzen.

• Programmiert soll das System in Perl wegen seiner guten Textverarbeitungsfunktionen und natürlich CPAN werden. In PHP ist der Rückgriff auf vorgefertigte Module deutlich schwieriger (PEAR macht keinen Spaß). Außerdem ist Perl auch besser für Nicht-Webserver-Umgebungen geeignet (z.B. beim Aufruf durch einen post-commit-hook). mod_perl soll dabei optional sein, ist aber empfehlenswert.
• Als Speichersystem ausschließlich SVN, und zwar sehr intensiv.
  • Abgesehen davon Flatfiles zur Speicherung von globaler Konfiguration, keine Datenbanksysteme.
  • Verwaltung von mehreren Reposities, d.h. mehreren Projekten, in einer Wikiinstallation.
  • Dabei kann jedes Projekt seine eigenen Einstellungen in Bezug auf Sicherheit (ACLs? Authentifikation?) und ähnliches (Standardmarkuptyp, ...) haben
  • Commits können entweder nach jedem Wiki-Edit geschehen (nach dem klassischen Wiki-Prinzip eine "Live-Bearbeitung") oder manuell gestartet werden (praktischer bei umfangreichen Projektarbeiten)
• Offenes System
  • Dank der Verwendung von SVN kann man auch auf lokalen Computern Arbeitskopien runterladen und dort am Inhalt arbeiten wie in der Wiki (natürlich ohne Webfrontend, aber dafür mit Editor und Bildbearbeitungsprogramm). Nach einem Commit erfährt die Wiki über die Änderungen und führt ggf. ein Update seiner Arbeitskopie durch, nötigenfalls durch manuelle Entscheidungstreffung im Websystem (z.B. nach Anmeldung einer authentifizierten Person).
  • Vielleicht ist es auch möglich, ein anderes Verzeichnis zu überwachen, in welchem eine weitere Arbeitskopie gepflegt wird und auf welches per FTP zugegriffen wird. So könnte man alternativ per FTP Commits begehen.
• Modularisierung von Markup und Dateitypen:
  • Wikisyntax/markupunabhängigkeit. Die Interpretation von Markups soll komplett modularisiert ablaufen, sodass neben (exemplarisch) "MediaWiki"-Markup auch reines HTML, "plaintext", SSI, theoretisch sogar RTF oder LaTeX möglich sein soll.
  • Dateitypunabhängig. Neben Textdateien (bzgl. Markup siehe oben) soll jeder beliebige Dateityp verwaltbar sein, wie ihn ein SVN nun auch speichern kann. Auch dies könnte komplett modularisiert ablaufen, sodass beispielsweise für Bilder ähnliche Übersichtsseiten wie bei der Mediawiki dargestellt werden könnten, die neben dateiimmanenten Metadaten auch zusätzliche Beschreibungsseiten einbinden könnten.
• Perfomance der gesamten Anordnung
  • Mit Perl-Caching-Modulen können die Wikiwebseiten gecachet werden – mehr Perfomance auf Kosten von etwas Festplattenspeicherplatz
  • Die Wiki dient nur zur SVN-Betrachtung und zum Bearbeiten. Über einen Post-Commit-Hook wird der Inhalt zu einem Platz abgegriffen, der anschließend von den Webseitenbesuchern gesehen wird.
  • Dadurch kann automatisch eine statische Website generiert werden.
  • Keine Datenbank oder Rootrechte erforderlich; ausschließlich min. ein eigenes SVN-Reposity, und damit wenig Administrationsoverhead.

Abgrenzung zu anderen Wikis

Es gibt bereits unzählige von Wiki-Implementierungen. Der Vergleich mit diesen kann vielleicht näher beleuchten, welchem Zweck SVNwiki dient:

Wie man sieht, wird kein gesteigerter Wert auf typische, mittlerweile gängige Wiki-Funktionen wie Kategorien, abgefahrenen Linktechniken (CamelCase oder so ein Müll), WYSIWYG, ACLs oder ähnlichem Berechtigungskram, Benutzereinstellungen, -seiten, Blogs oder ähnlichem Schnickschnack gelegt. Auch ein besonderes Hooksystem zwecks Erweiterbarkeit ist nicht geplant – durch die Modularität und Transparenz sollte es auch so recht einfach sein, das System zu erweitern.

Bei SVNwiki stehen die Wikifunktionen nicht im Vordergrund, sondern das SVN. Ergo wird es für Außenstehende vielleicht eher den Eindruck von Mozillas Doktor erhalten. Da nicht viele Leute damit arbeiten werden, gibt es keine großen Benutzergruppen – einfach angemeldete Benutzer und das wars.

Dateitypen

Die Behandlung von Dateitypen läuft modularisiert und objektorientiert. In einem Unterverzeichnis filetypes sollen Perl-Module für unterschiedliche Dateitypen installiert sein. Jeder Dateityp definiert vier Grundeigenschaften:

1. editor: Ein dateitypspezifisches Editiersystem (z.B. eine Seite mit textarea oder ein Uploadformular)
2. wikiviewer: Ein dateitypspezifisches Betrachtungssystem im Wikisystem
3. exporter: Ein dateitypspezifisches Betrachtungssystem außerhalb des Wikisystems (also im Bereich, den der Besucher letztlich hauptsächlich sieht)
4. actions: Dateitypspezifisch mögliche Aktionen zum Behandeln der Datei, die im Wikisystem angezeigt werden (z.B. history, edit, move, upload, ...)

Exemplarische Dateitypen mit ihren Eigenschaften
Legende: - nicht vorhanden, " vererbt von Vaterklasse (d.h. identische Eigenschaft)

	generic.pm (abstract)	text.pm extends generic	markup.pm extends text	binary.pm extends generic	image.pm extends binary
editor	-	Seitenbearbeitung (textarea, Zusammenfassungszeile, ...)	" (ggf. mit Syntaxhighlighting)	Bearbeitung der bin-desc-Seite	"
exporter	raw binary	" (=Text, plain, ohne irgendwas)	Syntax interpretiert (Ausgabe als HTML), in einem spezifischen Templatesystem	"	"
viewer	-	Text im Wikitemplate	", bei HTML o.ä. ggf. "nested" oder im Frameset	Die bin-desc-Seite, die die bin-history und Metadaten anzeigt (Mediawiki-ähnlich)	Einbindung des Bildes als , Exif-Metadaten anzeigen
actions	history, move, delete	" + edit	"	" + edit + upload	"

Zusatzaktionen, Erweiterbarkeit

In den vier dateispezifischen Grundeigenschaften wurden auch Aktionen genannt, was mit Dateien gemacht werden kann. Diese lassen sich beispielsweise erweitern um Aktionen wie new, what-links-here, usw. Möglicherweise könnte man dazu ein Spezialseiten anlegen, die durch Module bereitgestellt werden (ähnlich dem sehr flexibelen System, wie es Mediawiki macht).