[linux-l] Wiki-Grundsatz-Diskusion

Volker Grabsch vog at notjusthosting.com
Do Mai 4 16:16:32 CEST 2006


On Tue, May 02, 2006 at 11:11:39AM +1000, Peter Ross wrote:
> >Egal. Der (Ausgangs-) Punkt ist, das man nicht einfach Wiki, DB, VC,
> >_was_immer_ ... auswechseln kann. Es fehlt die Möglichkeit eines Dump's.
> 
> Wirklich?

Olaf hat nicht ganz unrecht. Wenn ich die Wiki-Artikel und -Diskussionen
zunächst in einer MySQL-Datenbank habe, danach aber lieber als Backend
einen SVN-Server und einen NNTP-Server haben möchte, kann ich das nicht
wirklich herumschieben.

Andererseits stellt sich aber auch die Frage, wozu man einen Riesen-
Dump braucht. Ist das Wiki ein Monolith, dann vielleicht. Aber will ich
z.B. die Wiki-Diskussionen in einen Newsserver oder eine Mailingliste
bringen, bin ich sowieso erschossen.

Habe ich hingegen vorher die Diskussionen im Newsarchiv gehabt, dürfte
das Übertragen zu einem anderen Newsserver kein großes Problem sein.
Auch zwischen Versionskontrollen kann man schon halbwegs vernünftig
portieren.

Ich persönlich fände es bei den Dumps allerdings wichtiger, dass man
das Problem an der Wurzel packt. Immerhin geht es nicht nur darum,
Wiki-Artikel von einem Wiki ins andere zu transportieren, sondern
genauso auch darum, überhaupt Dokumente von einer Versionskontrolle
in eine andere zu übertragen. Zumindest ein vereinfachter gemeinsamer
Nennen für alle SCM wäre da wirklich wünschenswert.

Auf diese Weise würde ein ein Wiki-Dump vielleicht aus 3 Dump-Dateien
bestehen (Artikel, News, Sonstiges), aber dafür könnte ich mit diesen
3 Sachen danach machen, was ich will. Die News z.B. auf irgendeinen
Server-Server importieren, die Artikel in ein SVN-Repository, etc.

So könnte man, neben den klassischen Variaten, zusätzlich noch ein
Wiki aufbauen bzw. zerlegen. (d.h. von SCM+News -> Wiki, bzw. wenn
einem die Wiki-Server Probleme bereiten, zurück von Wiki -> SCM+News).

> >Wenn
> >du dutzende Komponenten zusammen stückelst wird es alles nur noch 
> >schlimmer.

Kommt drauf an. Gibt es für die 3 Komponenten keine Standards, dann ja.

Aber für News z.B. gibt es da was gutes (ich glaube, jeder kann simples
MBox importieren/exportieren, korrigiert mich, wenn ich mich irre).

Für Versionskontrollen gibt es noch nichts, außer vielleicht das SVN-
Dump-Format, aber hier sollte man lieber etwas schaffen, was gleich
SCM-übergreifend ist, nicht nur wiki-spezifisch.

Das, was dann übrig bleibt, braucht nur noch ein extra Format.
Wozu ein neues Riesen-Format definieren, wenn es zwei wesentlich
kleinere ebenfalls tun, die einem sogar *noch* mehr Flexibilität
bieten, als den bloßen Umstieg von Wiki->Wiki ?

> Du bist viel flexibler, wenn Du das Diskussionsforum aussen vorlaesst.
> 
> Es ist ein separates Modul, gehoert nicht in die Wiki-Spezifikation.
> 
> Moeglicherweise brauchst Du ein Standard-Protokoll fuer Diskussionforen. 
> Bevor ich aber ein neues definiere, wuerde ich mich genau umgucken, ob's 
> nicht schon etwas gibt.
> 
> News fiel mir fuer diesen Punkt gerade ein, weil dort die ganze 
> Infrastruktur schon da ist. Gib Deinem Forum eine Schnittstelle zu nntp 
> und Du bist aus dem Schneider.

Das ist ein interessanter Punkt.

Statt von Newsservern zu erwarten, WikiXML zu sprechen, könnte man von
den (sowieso neu zu entwickelnden) Wiki-Clients verlangen, NNTP zu
sprechen. ... oder alternativ einen externen Newsreader zu öffnen.

---------------------

Das WikiXML-Protokoll könnte entschlackt werden, indem der Server
dem Client eine URL gibt. Vielleicht legt WikiXML fest, dass dies
eine nntp:// URL sein muss. Viellecht ist das auch witzlos, und z.B.
auch http:// wird erlaubt, falls jemand sein Wiki-Diskussionsforum
ausschließlich per Webinterface anbietet. Der Punkt ist, dass man
freie Wahl hat. Mehr Möglichkeiten mit weniger Aufwandt.

Der Nachteil dieses Ansatzes ist, wie Olaf und ich bei dem Treffen
festegestellt haben, dass man die "Logik" nicht ohne weiteres mehr
einspeisen kann. Wikispezifische Sonderregeln kriegt man nicht ohne
weiteres in das NNTP.

---------------------

Zum Tragen kommt das vorallem bei der Versionskontrolle. Hier sind
die Protokolle von CVS, Subversion, etc. zu schwach. Ein gemeinsames
Protokoll für alle SCM wäre wirklich wünschenswert, und das ist im
Prinzip mein erster Gedanke gewesen. Für ein einfaches Wiki-Protokoll,
wenn man sich auf eine bestimmte Wikisprache festnagelt, braucht man
nicht mehr, und man könnte es wahlweise mit seinem SCM-Client oder
einem Wiki-Tool bearbeiten.

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.

---------------------

Die grundsätzliche Frage ist also tatsächlich, ob die vorhandenen
Protokolle ausreichen oder nicht. Für ein Arbeits-Wiki, in dem ich
Wiki-Dokumente und Quellcode im selben SCM verwalten möchte, *will*
ich gar keine Wikipedia-artigen Aktionen, sondern stattdessen lieber
die Möglichkeit, sowohl über das Wiki als auch direkt an die Wiki-
dokumente im SCM heranzukommen. In der Wikipedia ist solch ein
"direkter Weg" vielleicht nicht erwünscht, aber gut, man muss ihn
ja auch nicht anbieten. Die Wikipedia gibt ja auch niemanden direkten
Zugang zu den MySQL-Tabellen.

(der Vergleich hinkt, da SQL völlig ungeeignet zum Bearbeiten und
einchecken von Wiki-Artikeln ist, wohingegen ein SCM-Protokoll sehr
gut geeignet ist)

---------------------

Nun bleibt also die Frage, was am Wiki-Protokoll so speziell ist.

Man könnte Teilaufgaben an NNTP und ein einheitliches SCM-Protokoll
delegieren, und im WikiXML nur das festlegen, was übrig bleibt, z.B.
das Dokumentenformat. Das halte ich für einen sehr einfachen und
mächtigen Ansatz, würde aber nur einen Teil der von Olaf beschriebenen
Problematik lösen.

Vielleicht ist die Wiki-Problematik so speziell, dass NNTP nicht für
Wiki-Diskussionen verwendet werden kann, da es gewisse Konsistenz- und
Kontroll-Mechanismen nicht zur Verfügung stellt. In diesem Fall wäre
es aber auch unmöglich, die bestehenden Newsreader mit einem neuen
Protokoll auszustatten. Wenn dies nämlich möglich wäre, müsste es auch
möglich sein, das Wiki-Protokoll in NNTP umzuwandeln, und wenn das
möglich ist, könnte man auch gleich von vornherein NNTP verwenden.

> >Ob du dein News-Server vergewaltigst ist mir egal, solange der news-server
> >WikiXML unterstützt wird oder die MiddleWare die News-Server benutzt.

Olaf, jetzt verdrehst du aber selbst das Protokoll und die Implementierung.
Sicher kann man einen News-Server als Backend für Wiki-Diskussionen
benutzen, oder eben nicht. Aber darum geht es gar nicht.

Es geht um das Protokoll nach außen. Wird nach außen hin NNTP angeboten,
kannst du beliebige Newsreader ranhängen. Es ist dann egal, ob nun ein
selbstgeschriebener zentraler Wiki-Server unter anderem die News verwaltet,
oder man einen separaten Standard-News-Server verwendet. Jenachdem, wie
man's braucht.

Willst du hingegen erst gar keine klassische Diskussions-Struktur, nun
gut, dann brauchst du eh spezielle Clients.

Olaf, du hast häufiger von abgespeckten Protokoll-Versionen des Wiki-
Protokolls gesprochen. Denn die gesamte Fülle kann ohnehin nur von
Spezial-Clients erfüllt werden. Die abgespeckte Version ist also dafür
da, dass dies irgendwann von existierenden Servern und Clients
gesprochen werden kann, z.B. Newsreadern oder Subversion-Servern.
Aber diese abgespeckte Version wird ihr Ziel verfehlen, wenn sie
einerseits so abgespeckt ist, dass sie z.B.
technisch nicht mehr verlangt als z.B. NNTP,
aber vom Client erwartet, eine völlig andere Protokoll-sprache zu
implementieren.

Dann sollte man diese abgespeckte Protokoll-Version gleich z.B. in
NNTP umgewandelt werden, dann unterstützt man nämlich gleich
automatisch alle Newsreder.

Was ich damit sagen will: Auch das abgespeckte Protokoll wird nur
von neuen Clients unterstützt werden, in existierende Programme wird
man es nicht hineinbekommen. Will man Wiki-Diskussionen über Newsreader
zugänglich machen, muss man NNTP nach außen anbieten.

Eine abgespeckte Protokoll-Version verfehlt also ihr Ziel (oder war
es gar nicht dein Ziel, bisherige Clients zu unterstützen?) ... dann
doch lieber z.B. NNTP und das "svnserver" Protokoll unterstützen.

Die Frage ist nur, ob auch umgekehrt ein "full featured" Wiki-Client
mit dem Wiki-Server über NNTP und das SVN-Protokoll kommunizieren kann.
Wahrscheinlich nicht. Es wird sicher einige Features geben, die ein
Wiki-Server und Wiki-Client unterstützen, aber nicht in den Sprachen
des NNTP bzw. SVN-Protokolls ausdrücken können. (jedenfalls nicht, ohne
sie zu vergewaltigen, aber das wollen wir ja alle nicht). Für diese
Extra-Features müsste man dann noch ein eigenes Protokoll entwerfen.

Man könnte dieses Extra-Protokoll natürlich erweitern, um die News-
und SCM-typischen Fähigkeiten, aber was hätte das für Vorteile?
Natürlich, man braucht nur einen Port, und eventuell wäre es leichter
zu implementieren (vorallem beim SVN-Protokoll). Aber wenn der Wiki-
Server irgendwas anderes als Wiki-Clients bedienen können soll, muss
er eh NNTP oder ähnliches sprechen können.

Und wenn ein "full featured" Wiki-Client nicht nur mit echten Wiki-
Servern reden können soll, was dann? Würde er ohnehin in NNTP und
SVN-Protokoll reden, dann könnte man ihn auch direkt an einen
Subversion-Server und einen News-Server anklemmen. Ein paar Features
weniger, aber man bräuchte keinen Spezial-Server. Falls der Wiki-Client
jedoch ein 100% ausgedachtes Protokoll spricht, würde man von SVN- und
News-Server verlangen, dass sie dieses extra Protokoll beherrschen.
Oder man müsste einen Mini-Wikiserver schreiben, der nichts weiter
tut, als das Wiki-Protokoll ins SVN-Protokoll und NNTP zu übersetzen.

Es würde also ganz und gar nicht passen. Statt die NNTP- und SVN-
Protokolle als Teil eines Wiki-Protokolls zu definieren, würde man
stattdessen von sämtlichen Newsreadern, SCM-Clients, News-Servern
und SCM-Servern verlangen, das Wiki-Protokoll zu sprechen. Wäre das
nicht "genau falschrum"?

> Hinter einem Wiki steht ein Inhalt und eine Versionskontrolle. Wenn Du 
> eine einheitliche Schnittstelle fuer CVS, Subversion etc. hast, bist Du 
> eigentlich aus dem Schneider.

Das war auch meine Idee. Aber es erfüllt wiegesagt nicht alle Ansprüche.
Auf jeden Fall wäre es schonmal eine deutliche Verbesserung.

> Dass das nicht so einfach ist, auf Grund unterschiedlicher 
> Heransgehensweise, wurde in dem letzten Thread ueber Versionskontrolle 
> doch recht deutlich.
> 
> Ein Wiki braucht allerdings nicht allzuviel, man muss es nicht 
> kompilieren;-) Du brauchst, um eine Wiki-gerechte Versionskontrolle zu 
> haben, nicht viel mehr als CVS bietet.

ACK. Aber selbst wenn dieses, nennen wir mal, SimpleCVS Protokoll
von CVS unterstützt wird, direkt oder durch einen Wrapper, sollte man
es dennoch nicht unbedingt gleich nach außen anbieten.

Ich denke, einige Diskussionen sind deshalb schiefgegangen, weil man
aneinander vorbeigeredet hat, welche Programme sich in dieser Sprache
(d.h. in diesem Protokoll) unterhalten.

Der Wiki-Server z.B. könnte auf diese Weise seine Seiten ablegen.
Er redet mit irgendeinem SCM via SimpleCVS, um Seiten abzulegen oder
zu holen. Manchmal ist das sinnvoll. Komplexere Wiki-Server führen
vielleicht parallel dazu noch eine Datenbank, oder machen gleich alles
in ner Datenbank. Einfache Wiki-Server brauchen jedoch vielleicht
wirklich nur ein SCM, das SimpleCVS spricht, und nichts weiter.

Ein Wiki-Server könnte aber auch SimpleCVS nach außen anbieten. Natürlich
sollte er nicht alle SimpleCVS-Aktionen direkt zum Backend leiten,
sondern noch Konsistenz-Prüfungen etc. anstellen. Im Falle der Wikipedia
müsse er z.B. noch überprüfen, ob die zu ändernde Seite momentan gesperrt
ist, und ähnliches. Vielleicht hat er auch gar kein SCM als Backend,
sondern ne Datenbank. Dann könnte er aber trotzdem SimpleCVS nach außen
anbieten.

Aus Sicht eines sehr primitiven Wiki-Clients, der vielleicht nur
SimpleCVS sprechen kann, wäre es dann egal, ob er mit einem "full featured"
Wiki-Server, oder mit einem gepatchten CVS-Server redet.

Genauso wäre es dem CVS-Server egal, ob seine Dienste nach außen
direkt angeboten werden, oder ob ausschließlich ein Wiki-Server auf
ihn zugreift, und alles über den Wiki-Server geht.

> Was dann eine Versionskontrolle als DB-Backend hat, ist dem Wiki voellig 
> egal.

Mag sein, aber zu einem einheitlichen SCM-Protokoll gehört auf jeden
Fall auch ein einheitliches Dump-Format. Oder man nutzt das Protokoll
direkt als Dump-Format, wie bei SQL.


Viele Grüße,

    Volker

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



Mehr Informationen über die Mailingliste linux-l