[linux-l] Wiki-Grundsatz-Diskusion

[Volker Grabsch]

On Mon, Apr 17, 2006 at 12:28:46AM +0200, Olaf Radicke wrote:
> Ich fasse mal in meinen Worten zusammen:
> "Es braucht eine standardisierte Wiki-Sprache und definierte Schnittstellen" - 
> Richtig?

Nein, definierte Schnittstellen reichen.
Mit mehrere Wikisprachen kann ich leben, das halte ich sogar für sinnvoll,
je nach Anwendungszweck gibt es da nämlich erhebliche Unterschiede.

Obwohl die Entkoppelung von Wikisprache und HTML/PDF/...-Generator auch nett
wäre, keine Frage. Darüber hab ich mir auch schon Gedanken gemacht.
Aber das ist ein anderes Thema, und viel komplexer. Nimmt man
"Wikisprache+Generator" als Einheit an, käme immer noch eine super
Architektur raus, die alles bisherige an Einfachheit und Potential
überschattet.

Trennt man zwischen Sprache und Konverter (also zwischen Parser und
Generator), so würde aus meiner vorgeschlagenen dreiteiligen Architektur
eine vierteilige werden.


Zum Thema "viele Sprachen" nochmal: Man vergleiche die MediaWiki-Sprache
mit ReST (für Python-Dokumentation gern benutzt).

ReST ist im Plaintext sehr gut lesbar. Jede halbwegs übersichtliche
README könnte ein gültiges ReST-Dokument sein.
Nachteil: Mehr Tipparbeit, z.B. bei Überschriften.

ReST:
    Überschrift
    -----------

MediaWiki:
    = Überschrift =

MediaWiki ist im Quellcode gut zu tippen. Überarbeitungen an größeren
Texten müssen nur selten durch irgendwelche Anzahlen von "=" oder "*"
Zeichen angeglichen werden.
Nachteil: Der Quellcode ist nicht so gut lesbar. Für ne README bräuchte
man auf jeden Fall noch einen MediaWiki -> Text Konvertierer.
(na gut, man hat schon MediaWiki -> HTML, da klemmt man ein "w3m -dump"
hinter, geht recht gut. ;-))

Dieses einfache Beispiel zeigt, dass es eine gemeinsame Wikisprache
nicht geben kann, wohl aber ein gemeinsames Dokumenten-Format. Gute
Kandidaten wären ein *sehr leicht* parsebares Textformat, oder gleich
ein XML-Format. Ich dachte da an sowas ähnliches wie Docbook, nur ohne
die ganzen Design-Mängel in der Sprache. Problem ist, dass das bereits
probiert wurde, mit TBook. Und die Docutils machen auch sowas ähnliches,
nur dass sie ihr Zwischenformat nicht serialisieren, sondern als Baum
im Speicher haben.

Mein persönlicher Anspruch an solch ein Zwischenformat wäre auch
Neutralität bezüglich Web und Druck. Das ist besonders bei Verweisen
kritisch. Außerdem verlange ich eine strenge Trennung von Inhalt und
Form, möglichst kein Einschleusen von HTML oder LaTeX-Schnipseln.
Spätestens jetzt wird's ungemütlich. Ideal für Dokumentationen, aber
für reine Web- oder reine Druckanwendungen eventuell nicht mehr
tauglich. Es erwartet eine andere Herangehensweise, die einige
Umstellung bedeutet, von und LaTeX inspiriert ist, aber das würde
hier zu weit führen.

Ein völlig anderer Ansatz wäre ein Universalparser, der jede Wikisprache
in Nullkommanix in ein beliebiges anderes Format umwandelt. Für
Programmiersprachen gibt's bereits Grammatiken, und entsprechende
Parsergeneratoren. Das kann man aber nur selten auf Wikis anwenden:
die Grammatiken sehen grausam aus. Man braucht was anderes. Ich hab
mir den Kopf zerbrochen und mir ist nichts gutes eingefallen, aber
eines Tages bin ich über "atox"  (ASCII to XML) gestolpert:

    http://atox.sourceforge.net/

Genau so hat das auszusehen! So muss es gemacht werden. Der Autor
dieses Programmes, auch wenn es noch Beta-Stadium ist, hat IMHO die
richtige Grundidee und den richtigen Riecher dafür.

Wenn es eines Tages wirklich so billig sein sollte, einen Textparser
zu schreiben, dann ist es fast egal, ob man die strenge Trennung in
Parser und Generator überhaupt braucht. Dann hätte man die Wahl, ob
man gleich HTML erzeugt, oder unser Super-Zwischen-Format, für das
es dann entsprechende Konverter nach HTML/LaTeX/PDF/... gibt.

> Danke für die Einladung zu deinem Projekt. Es hat über Haupt nichts mit deiner 
> Idee oder Person zu tun. Ich finde http von Prinzip zum Kotzen. Das ist ein 
> toter Gaul. Das ist doch alles nur deshalb so krank, weil mit http/html Dinge 
> gemacht werden, wo für sie nicht gedacht sind.

Ich finde HTTP für SOA sehr gut geeignet, zumindest alles, was
stringbasiert ist, also alle leichtgewichtigen Sachen. Würde ich
eine Applikation übers Netz fersteuerbar machen wollen, wäre simples
HTTP + GET/POST meine erste Wahl.

Vorallem, weil ich dann *eine* Schnittstelle habe, die sowohl für
Menschen als auch für Programme benutzbar ist.
Leider werden die meisten Sachen verkompliziert, sodass die Interfaces
nur noch für eins von beiden taugen.

> Es war in http/html weder Sitzungen vorgesehen, noch Event-Handling, noch 
> Verschlüsselung, noch Multimedia oder sonst was.

Stimmt. Sowas sollte man entweder konsequent mit JavaScript machen, oder
gleich ne GUI z.B. mit GTK+ basteln.

An der Stelle hört's wirklich auf. Andererseits ist AJAX wirklich ein
sehr nettes Spielzeug, mit dem man tolle Sachen machen kann. :-)

> Das wird jetzt alles mit 
> nachtäglichen Frickel-Scheiß rein gequetscht. Cookies, CGI, PHP, 
> Apache_mod's, Javascript, Java applets, SSL, MD5-Chek, Macromedia Flash, GIF, 
> Schlag_mich_tot...

Ich stimm dir zu, bis auf SSL. Das finde ich sehr sinnvoll.

Und JavaScript, wenn man damit wirklich eine komplette GUI bauen möchte,
dann aber bitte auf den ganzen anderen Schrott verzichten.

> Das ist doch alles Schrott! Benutzt du als Mail-Reader das Web-Interface von 
> GMX? Oder benutzt du das Google-Web-Interface für News-Groups? Oder den 
> Therminplaner von GMX über Web-Inteface ? Warum nicht? Weils scheiße ist!

Aber es ist immer ne gute Notlösung. Nen Browser hast du in jedem
Internet-Café. Jederzeit an seine Mails ranzukommen hat was.

Effiziente Bedienung kriegt man natürlich nicht rein, obwohl JavaScript
auf einem guten Weg dahin ist. Aber JavaScript ist in meinen Augen kein
"Web" oder "HTTP" mehr, das ist nen standardmäßig installierter
Interpreter.

IMHO sollte aber lieber überall ein Python-Interpreter standardmäßig
installiert sein. ;-)

> Wenn es ein definiertes (TCP/IP-)Protokoll für Wikis gäbe, wäre ja schon viel 
> gewonnen! Dann kann ich mir mein Interface selber wählen. So wie ich jetzt 
> frei entscheiden kann, mit was ich meine News-Groups und Mails lese. 

Dieses Protokoll würde ich schon auf HTTP aufsetzen wollen, denn
service-orientiert ist immer gut, dann kann man es auch automatisiert
ansprechen, also per Script, ohne dem Script nen neues Protokoll
beibringen zu müssen. Außerdem kann man es in seinen Apache mit
intergrieren.

> Also:
> 
> A) Rohdaten (in "WML" Wiki Markup Language)

Ich hab's WikidoXML genannt, ich glaube, WML hat schon eine andere
Bedeutung.

> C)  Versions System (intern mit oder DB) mit standardisierter Abfragesprache

... was ist B)  ?

Jo, eine einheitliche API für alle gängigen VCS, also CVS, Subversion,
Darcs, Mercurial, GIT wäre ne Menge wert. Eine für die MediaWiki-MySQL-
Versionskontrolle, und dann vielleicht noch Plaintext hinzu.

> D) Wiki-Server mit  TCP/IP und eigenem standardisierten Protokoll

Nett, aber wieso kein VCS-Client? Ich meine, hey, das ist ein VCS, das
kann man auch direkt ansteuern: Wiki-Quellcode in Form von Textdateien
bearbeiten, und dann z.B. "svn commit".

Soll es Remote laufen, gibt es doch eh keine Sessions (HTTP Auth reicht
völlig, im Prinzip machen die ganzen VCS es ja auch nicht anders, und
eine extra Authentifikation pro Seiten-Commit ist IMHO nicht zu viel
verlangt) ... von daher könnte man auch ein ganz, ganz einfaches
HTTP+Post verwenden, denn was muss dieses Protokoll denn sonst groß
leisten?

> C) Wiki-Klient (Qt, GTK, Tcl/Tk, Ncurses, Komando-Zeile, oder oder auch 
> HTML-Frickel-Kacke)

... meinst du E) ?   ;-)

> Also Vier-Schicht-System.

Ich sehe bei deinem Vorschlag grundsätzlich das Problem, dass zu wenig
existierendes wiederverwendet wird. Man sollte IMHO den Direktzugriff
auf das VCS mit einplanen. Dorthin sollten die Clients sich verbinden,
und dieses sollte Authentifikation/Autorisation übernehmen, sowie
den Netzwerk-Kram.

Zusätzlich noch eventuell ein HTTP-Interface, aber eigentlich nur für
die exotischeren Versionskontrollen, wie etwa das MediaWiki-MySQL-VCS.

Was ich richtig sauber fände, wäre ein "Wiki-Client", der letztlich
nur ein allgemeiner VCS-Client ist, mit dem man also genausogut auch
schnell mal nen kleines Shellscript nachbearbeiten kann, dass in einem
entfernten Subversion-Repository liegt.

Das VCS also nicht als "Backend-Blackbox" missbrauchen, sondern offen
spezifizieren, wie's darin aussieht: Ein Verzeichnis, und jeder Wiki-
Artikel ist eine versionierte Datei. Vielleicht erlaubt man auch
Unterverzeichnisse, und legt noch UTF-8 als internes Encoding für die
Dateinamen fest, falls nötig. (in Subversion ist das AFAICS sowieso
schon der Fall)

So kann ich Wiki-Artikel mit meinem Lieblings-Editor bearbeiten, und
einer normalen Versionskontrolle. Bei einigen Backends könnte man so
auf einen speziellen Client sogar verzichten.
(... hat aber keine Vorschau, und bei der Wikipedia wäre das
Arbeitsverzeichnis ziemlich groß, man sollte die tatsächlich
ausgecheckten Dateien also besser kontrollieren können.)

> Tut mir Leid für die unflätige Ausdrucksweise. Bei http/html kann ich immer 
> nicht an mich halten.

Ich verstehe, was du gegen ein klassisches Webinterface hast, aber
HTTP als Grundlage für ein Wiki-Protokoll ist IMHO nicht schlecht.
Was gibt es denn großartig an Aktionen? "read" und "commit", oder?
Dafür brauchst du keine Sessions und keine Cookies, normales HTTP
ist gerade für dieses Protokoll IMHO sehr geeignet.

HTTP-Auth und SSL liefern zwar Overhead bei jeder Verbindung, aber
ich glaub nicht, dass das an die Performance geht. Wikipedia hatte
doch Probleme mit dem ausgelasteten MySQL-Backend, nicht mit den
Overheads der HTTP-Verbindungen, oder?

Dass man zusätzlich noch via Webinterface darauf zugreifen kann,
ist ein nettes Feature, das man quasi mit geschenkt bekommt, für
die, die's brauchen.

Würde man beim MediaWiki den Login-Button weghauen und stattdessen
HTTP-Auth benutzen, wäre das IMHO eine sehr saubere Sache, sowohl
für Menschen als auch für Programme gleichermaßen gut bedienbar.

> Ich werde mir mal Tomboy ( http://en.wikipedia.org/wiki/Tomboy_(software) ) 
> ansehen...

... sieht nett aus.  :-)


Viele Grüße,

    Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR