[linux-l] Wiki-Grundsatz-Diskusion

[Volker Grabsch]

On Wed, May 10, 2006 at 11:03:39PM +1000, Peter Ross wrote:
> >Aber auch hier das Problem, dass Wiki-Besonderheiten nicht eingepflegt
> >werden können. Seien es Bedingungen an das Format der Seiten, seien
> >es Echtzeit-Benachrichtigungen, oder sonst irgendwas.
> 
> Versionskontrollen haben Triggerscripte. Hier koennen 
> Plausibilitaetspruefungen, Lockingprobleme und Benachrichtigungen 
> stattfinden.

Olaf und ich haben das bereits durchgespielt. Trigger sind nett, aber
wären im Falle einer "zweiten Wikipedia", die darüberhinaus all seine
Ansprüche erfollen soll, extrem komplex. Da stellt sich wirklich die
Frage, ob ein eigenständiger Server nicht das geringere Übel ist.
Genauso die Performance: Was ist, wenn das Wiki zu groß wird?

> Das waere auch ein Ort fuer die "XML-Normalisierung", um 
> festzustellen, was denn wirklich geaendert wurde oder wo jemand nur die 
> Tags eingerueckt hat.
> Das sind Dinge, die Du beim Einpflegen brauchst, aber nicht beim Dump.

ACK. Aber das ist eh nur ein Implementierungsdetail. Das gesamte Konzept
darauf basieren zu lassen, dass das Wiki unter einer bestimmten Versions-
kontrolle laufen muss, wäre nicht sehr geschickt.

Grundsätzlich wäre ein "Subversion" + "eigenständiger Newsserver" +
"Hooks" eine mögliche Implementierung. Das Protokoll sollte dies aber
nicht vorschreiben.

> >Nun bleibt also die Frage, was am Wiki-Protokoll so speziell ist.
> >
> >Man könnte Teilaufgaben an NNTP und ein einheitliches SCM-Protokoll
> >delegieren,
> 
> Wenn, wie oben als Beispiel mit den Triggerskripten genannt, die gesamte 
> Logik in das SCM verlagert werden kann, kann man mit einem SCM-Client 
> drauf zugreifen (z.B. mit Eclipse).

Mag sein, dann braucht man aber immer noch ein vereinfachtes,
einheitliches Potokoll für alle SCM.

> Wenn das nicht klappt, und man etwas "drueberlegen" muss, darf man die 
> untere Schnittstelle nicht nach aussen anbieten - ansonsten umgeht man 
> Kontrollmechanismen und alles wird inkonsistent.

Genau, an der Stelle habe ich auch gestutzt, aber ich habe längst
erklärt, warum das irrelevant ist.

> Die Triggerskripte gehoeren zur Spezifikation des Wikis dazu, da sie 
> Funktionalitaet des Wikis beschreiben.

Du vermengst hier aber ganz arg das Protokoll und die Implementierung.
Grundsätzlich sollte das Protokoll / die Protokolle alle nur denkbaren
Eigenarten verschiedener Wikis *unterstützen*, aber nicht vorschreiben.

Wenn jemand lieber ein eigenes SCM schreibt, das gerade die
Wiki-typischen Features unterstützt, und sonst nichts ... wieso
muss man dann dort Hook-Scripte festlegen? Wenn diese Funktionalität
dort schon fest eingbaut ist, und das Ding (vielleicht gerade deshalb)
sehr viel performanter ist, erfüllt es das Protokoll nicht mehr?!

Das Protokoll sollte natürlich sowas festlegen wie "normalisierung
des XML-Codes auf diese und jene Weise". Ob das nun per Hook-Script
geschieht oder fest in einem speziellen Wiki-SCM verdrahtet ist, darf
das Protokoll jedoch nicht vorschreiben.

> Tja, eine einheitliche SCM-Schnittstelle waere wirklich fein.

Allgemein wird es das nicht geben. Aber ein für, sagen wir, XML bzw.
Plaintext optimiertes Protokoll, nicht nur einheitlich sondern auch
einfach, wäre in der Tat eine nette Sache. Wie schon in vergangenen
Postings möchte ich dieses Protokoll einfach mal "SimpleCVS" nennen,
bessere Vorschläge sind willkommen. :-)

Das Wiki-Protokoll würde dann nur noch festlegen müssen: Benutze
"SimpleCVS" und "NNTP" für Seiten und News. Die Wiki-Seiten sind
im "WikiXML"-Format. Damit ist schon er größte Teil sauber spezifiziert,
und alle Punkte auf Olfas Wunschliste, die damit nicht abgedeckt wären,
würde ich dann in ein eigenes Protokoll verpacken. Auch dies hab ich
aber schon an anderer Stelle ausfühlich erklärt.

> Ich wuerde mich hier erst einmal versuchen, bevor ich mich auf ein den 
> Monolithen Wiki abdeckendes vollstaendiges Neudesign einer Wiki-Sprache 
> werfe.

Mein Ziel dieser "WikiXML"-Sprache ist eigentlich die Abdeckung eines
Dokumenten-Formats, das weitestgehend wirklich Inhalt beschreibt und
keine Form. Stattdessen sollte dann lieber das Entwerfen und Pflegen
eigener HTML- oder LaTeX/PDF-Stylesheets vereinfacht werden.

Dieses Format soll möglichst einfach und konsistent sein. Alles, was
zu speziell wird, kommt in "extra" Abschnitte, die dann so wie sie
sind ins Ausgabeformat gelangen (z.B. Formeln als LaTeX, Plaintext,
PNG)  Dabei wird das jeweils am besten geeignete Format benutzt.
(Hier habe ich mir schon viel überlegt und erkläre das auch genauer,
wenn Interesse besteht)

> BTW: Wie gut ist Wikipedia dabei, Hyperlinks auf andere Artikel upzudaten? 
> (wenn der Artikel von Alkohol nach Aethanol wandert.. was passiert mit dem 
> Link auf Alkohol im Artikel Suchtproblem?)

Das Problem ist auf höherer Ebene gelöst: URL-Abwärtskompatibilität.
Will sagen: Es gibt *keine* Updates irgendwelcher Links. Ein Link auf
den Artikel "Alkohol" wird immer auf die URL "http://.../wiki/Alkohol"
verweisen.

Wenn du den Artikel umbenennst, z.B. nach "Ethanol", dann kannst du
diesen Artikel nun über zwei URLs erreichen:

    http://.../wiki/Alkohol
    http://.../wiki/Ethanol

Ich finde, das ist die beste Lösung. HTTP-Weiterleitungen würden nämlich
nur nerven, und außerdem könnte es ja sein, dass auch noch völlig andere
Webseiten auf ".../Alkohol" verweisen, d.h. mit dem Update irgendwelcher
Wiki-internen Verweise hätte man sowieso nicht viel gewonnen.


Viele Grüße,

    Volker

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