[linux-l] Wiki-Grundsatz-Diskusion

[Volker Grabsch]

On Tue, May 16, 2006 at 02:19:33PM +0200, Olaf Radicke wrote:
> > *Das* habe ich ebenfalls mehrmals durchgekaut, Stichwort: 3 Dumpfiles.
> > Außerdem gibt es kein "Wikipedia-Format" ... höchstens SQL-Dumps und
> > Konvertierungsscripte.
> 
> Sag ich ja. Du sitzt in der Sch****. Egal wie du es wendest. Das 
> Konvertierungsscripte was Wikipedia-Diskusionen in NNTP umwandelt möchte ich 
> sehen...!

Was hat das denn damit zu tun? Es geht hier nicht um einen Migrationsplan
der Wikipedia, sondern

> [...]
> > Da könntest du genausogut sagen: Wikipedia und MySQL sind nicht
> > Teilmenge voneinander: Wikipedia kann z.B. keine beliebigen Tabellen
> > speichern, und MySQL hat kein Webinterface, Artikelverwaltung, etc.
> > Dennoch wird MySQL von der Wikipedia genutzt.
> 
> ...Ich gehe noch ein Schritt weiter: 
> Wikis und SQL sind weder des Einen noch des Anderen Untermenge. Die 
> Schnittmänge ist nicht großer, als die wischen Moped und LKW.
> 
> ...Ja, den Schraubenzier kann ich beim LKW genauso verwenden wie beim Moped. 
> Genau von dieser Schnittmenge sprach ich.

Nein, die Komponenten News-System und SCM sind in Wikis klar erkennbar
und relativ groß. Außerdem sind bessere SCM-fähigkeiten und bessere
News-fähigkeiten in einem Wiki (vorallem in der Wikipedia) hochgradig
wünschenswert. Ich denke daher, dass deine Analogie in vielerlei
Hinsicht überhaupt nicht passt.

> > Wikis nutzen auf sehr intensive und klassiche Weise eine
> > Versionskontrolle. Wikipedia hat selbst eine nachgebaut (auf Basis
> > von MySQL), andere Wikis verwenden direkt ein SCM. (z.B. RCS,
> > Subversion, ...)
> 
> ...Der Schraubenzier von Oben. Banal. Rechtfertigt nicht sich selber mit 
> Altlasten einzuschränken.

Das php-MySQL-gefrickel der Wikipedia ist eine Altlast, nicht jedoch
moderne SCM wie Mercurial oder GIT.

Und das Unterstützen von existierenden Protokollen ist erst recht keine
Altlast, solange sie gut geeignet sind. Ein einheitliches SCM-Protokoll
gibt es leider noch nicht, aber was NNTP angeht: Würde ein Wiki dieses
Protokoll unterstützen, wäre das IMHO ein enormer Fortschritt.

(ob intern tatsächlich ein Newsserver läuft, und ob dieser direkt oder
indirekt angesprochen wird, ist an dieser Stelle egal. Irgendeine
Schnittstelle nach draußen brauchst du für die Diskussionen, und NNTP
ist nicht schwerer als ein selbsterfundenes Protokoll, im Gegenteil,
wahrscheinlich sogar leichter zu implementieren)

> [...]
> > Falsch. Offline-Arbeiten sind *der* klassische Standard-Fall für
> > Branches und Merges. Jemand holt sich eine oder mehrere Seiten aus
> > der Wikipedia auf seinen Laptop, arbeitet im Urlaub daran, macht
> > auch mehrere "commit"s (also lokal aufgezeichnetete Änderungen mit
> > Logmessages). Sobald er wieder daheim ist, hat sich die Wikipedia
> > in der Zwischenzeit auch schon weiterentwickelt. Er hat einen
> > "Urlaubs-Branch", und es gibt den "Haupt-Branch" auf dem Wikipedia-
> > Server. Beide müssen nur "gemerged" werden.
> 
> Banal. Wenn es dir darum geht, das du im Urlaub beim Arbeiten nicht den 
> Überblick über deine eigenen Änderungen verlierst, kannst du für dich gerne 
> ein lokalen CVS/Subversion/... installieren. Wenn du das sehr exzessiv nutzt 
> und du glaubst Andere würden das auch, kannst du es in deinen Wiki-Klient 
> integrieren.

Okay, das ist definitiv ein Tiefpunkt in der Diskussion. Du schmetterst
so viele Vorschläge mit dem Argument ab, dass es deine hohen Ansprüche
nicht erfüllt. Aber Ansprüche, die andere stellen, interessieren dich
nicht?
(bessere SCM-fähigkeiten würden der Wikipedia IMHO *sehr* gut tun!
und nicht zu vergessen die vielen Wikis, die Projekte dokumentieren.)

Ich bekomme solangsam den Eindruck, du bist an einem allgemeinen
Wiki-Protokoll gar nicht interessiert, sondern an einem speziellen
Wikipedia-Protokoll.

> Der Rest der Wikigemeinde interessiert deine Zwischenschritte im Urlaub nicht. 
> sie interessiert nur das, was du commitest in den Server.

Mit der Masse der Wikigemeinde kannst du auch nicht argumentieren, die
nutzt nämlich nur den Browser, um mal schnell was du machen, und würde
sich niemals einen extra Client dafür installieren.

> Im Gegenteil. Ich habe es schon oft bei Wikipedia erlebt, das (besonders 
> Anonyme IP's) versucht haben wesentliche Veränderungen durch 10-20 kleine 
> Edits zu verschleiern.

Ja, und? Inwiefern würden bessere SCM-fähigkeiten dies verschlimmern?

> [...]
> > Außerdem: Eine echte Versionskontrolle für Wikis zu verwenden, *wird*
> > teilweise schon gemacht, wiegesagt.
> 
> Wenn das Wikipedia machen würde, kannst du dir die Kugel geben.

Das glaube ich nicht. Im Gegenteil, da steckt viel Potential hinter.
Momentan hat die Wikipedia auch eine Versionskontrolle. Nicht sehr
groß, vom Funktionsumfang her nicht mehr als RCS und etwas Merging,
und das in PHP zusammengeschraubt, mit ner SQL-Datenbank als
Zwischenschicht. Das sieht etwa so aus:

    Wiki  <->  eigenes SCM in PHP  <->  SQL-Datenbank  <->  Dateisystem

Das Benutzen eines normalen SCM würde so aussehen:

    Wiki  <->  normales SCM  <->  Dateisystem

    (das bezieht sich nur auf Artikel, Meta-Infos kommen natürlich
     weiterhin in die SQL-Datenbank)

Das heißt, in dieser letzten Architektur ist *grundsätzlich* sogar
mehr Spielraum für Optimierungen, weil das SCM den Beschränkungen der
SQL-Datenbank nicht ausgeliefert ist. Dass bisherige SCM noch nicht
performant genug sind, behauptest du zwar ständig, aber ich sehe
erstmal keinen Grund dafür, die Mercurial-Benchmarks sind z.B. sehr
vielversprechend.

Der eigentliche Vorteil des Umwegs über die MySQL-Datenbank ist IMHO
der, dass MySQL verteilbar ist. Und *dieses* Feature fehlt den
bisherigen SCMs, wenn ich das richtig sehe.

Das ist in meinen Augen bisher der einzige Grund, aus dem ich sagen
würde, dass es sinnvoll ist, ein SCM auf eine SQL-Datenbank aufzubauen.
Ansonsten wäre das einfach nur purer Overhead (oder "Altlasten", wie
du es so schön nennst).

> > Kannst du ein konkretes Szenario in der Wikipedia nennen, das besser
> > abgelaufen wäre, wenn sie diese Indirektion über Nummern machen würden?
> 
> Eines hatte ich schon genannt:
> http://de.wikipedia.org/wiki/Syntax_von_C-Sharp
> Das "#" kannst du nicht verwenden.

Wikipedia erlaubt diese Sonderzeichen nicht? Komisch, ich dachte, die
würden das einfach mit "%..." in der URL umkodieren.

> Oder:
> http://de.wikipedia.org/wiki/Pali-Kanon
> Hat ein Redikt auf Dreikorb. Im Buddhismus gibt es eine Reihe von Sprachen in 
> dem die Literatur und die Lehre ist.

Du willst in einer deutschsprachigen Enzyplopädie nicht nur
fremdsprachige Artikel-Namen, sondern außerdem komplett ungewohnte
Schriftarten?

> Pali, Sankskrit, Chinesisch, Japanisch, 
> Tibetanisch und mittlerweile auch Deutsch und Englich. Der Artikel Pali-Kanon 
> gab es zwischenzeitlich vier mal, jeweils unter anderer Überschrift. Das 
> Problem zieht sich quer durch das Portal:Buddhismus. Es gibt keine Einigung 
> welche Sprache als Premersprache verwendet werden soll. So gibt es eine wahre 
> Weiterleitungs-Schlacht.

Das sieht mir nach einem sozialen Problem aus, nicht nach einem
technischen. Diesen Umbenennungs-Krieg gäbe es doch genauso, wenn die
Artikel-URLs Nummern wären.

> Im Fliestext sehe ich nur "Biographie von B.B.King" verlinkt. Ich erwarte eine 
> Biographie von B.B.King, lande aber auf dem Artikel "Biographie".
> Oder wenn der Link [[King|Biographie von B.B.King]] lautet. mittlerweile wurde 
> der Artikel von "King" nach "B.B.King" umbenannt weil noch ein Artikel 
> M.L.King entstanden ist. jetzt lande ich bestenfalls auf einer Seite die mich 
> weiterleiten wird. Je nach dem ob ich zu M.L.King oder B.B.King will. Hätte 
> man Artikel-ID-Links:
> Biographie von B.B.King ([[ID:5259775]]) würde zu erst "...Biographie von 
> B.B.King (King)..." stehen und später (ohne manuelle Änderung): "...B.B.King 
> (B.B.King)..." Der Preis dafür ist, das man mit Klammern immer ein gewissen 
> Fremdkörper im Text hat.

Ich sehe jetzt, was du meinst. In der Tat ist das
"on-the-fly"-Umbenennen von Links ein nettes Feature. Aber ich sehe
nicht, was das mit der Nummer zu tun hat.

Ich meine, diese beiden Dinge sind doch unabhängig voneinander. Das von
dir beschriebene Feature funktioniert genauso auch ohne Nummern. Zum
Beispiel könnte man in der Wikipedia festlegen, dass alle Wiki-Links,
die kein "|" haben (also keinen festgelegten Text) mit dem aktuellen
Artikelnamen belegt werden. D.h. man schreibt:

    ... ([[Alkohol]]).

Dann wird Alkohol später in Ethanol umbenannt, und auf der Seite
erscheint der Link nun als "Ethanol" statt "Alkohol".

Unabhängig davon, ob man das will oder nicht: Mit diesen kryptischen
Nummern hat das nichts zu tun. Zumal es im Wiki-Quellcode viel
übersichtlicher ist, wenn dort ein Artikelname statt einer Nummer
steht. Das Feature "nachträgliches umbenennen von Wiki-Links" ist also
in jedem Fall möglich.

Wozu die Nummern?
Die machen URLs und Wiki-Quellcode IMHO nur schwerer zu verstehen.


Viele Grüße,

    Volker

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