[linux-l] Wiki-Grundsatz-Diskusion

[Volker Grabsch]

Hallo Olaf,

dein Anwendungsfall sieht für mich wirklich nach dem eines typischen
Wikipedianers aus, und ist definitiv eine gute Richtlinie für das Design
neuer großer Wikis.

Ich stelle jedoch fest, dass meine Ansprüche sich etwas von deinen
unterscheiden. Meine Vorschläge resultieren aus einem Anwendungsbereich,
der sich in zwei wesentlichen Punkten von deinem unterscheidet:

1) Ich arbeite zwar gern, aber nicht sonderlich viel, an der Wikipedia.
   Ich möchte ein Wiki zur Programm-Dokumentation haben. Das heißt, die
   Wiki-Seiten sollen Handbuch, Referenz und vielleicht sogar die
   Homepage eines Projektes sein.

   Ich möchte, dass diese Doku genau wie der Quellcode in ein und
   demselben VCS drinstehen, gemeinsam ausgecheckt werden können,
   und dass ich von meiner Arbeitskopie aus sowohl Quellcode als
   auch die Wikiseiten bearbeiten kann. Wiki-Seiten und Programmcode
   sollten gleichermaßen einfach nur versionierte Textdateien sein.

2) Ich möchte offline daran arbeiten können, auch größere Änderungen
   in der Doku (den Wiki-Seiten) machen können, und dabei lieber
   Konflikte lösen als Dateien zu blockieren.


On Mon, Apr 17, 2006 at 11:37:49AM +0200, Olaf Radicke wrote:
> Du hast immer noch zu viel HTML/http und CVS im Hinterkopf. Mit dir deutlich 
> wird, das beides unerträgliche Einschränkungen sind,

Wenn CVS als Blackbox hinter dem ganzen steht, handelt man sich nur
Nachteile ein, das ist richtig. Da das Subwiki intern auch ein eigenes
Subversion-Repos anlegt, statt sich an ein existierendes ankoppeln zu
lassen, ist das ebenfalls einfach nur nervig.

Ist dieses Backend jedoch transparent, erspart es einem viel Ärger,
man hat genauso viel oder wenig Probleme damit, wie mit versioniertem
Quellcode. Dann kann man einen VCS-Client mit allen Features nutzen,
und braucht eben keinen Spezial-Client.

Ein eigenes bzw. HTTP-basiertes Protokoll, mit eigenem Client oder
Browser, das sollte IMHO alles obligatorisch sein.


Nicht alle von dir beschriebenen Features brauchen überhaupt kein
neues Protokoll oder einen speziellen Client. Folgende Sachen kannst
du auch mit nem Subversion-Client haben, zusammen mit deinem Lieblings-
Editor und einem kleinen Script, das Vorschauen der Wikiseiten erzeugt:

> Dann klicke ich auf den Butten und mein Wiki-Klient öffnet sich genau so wie 
> ich ihn geschlossen habe. Mit den zuletzt geöffneten Artikeln und dem Laout 
> was ich mir in meiner persönlichen Konfiguration gespeichert habe. 
 
> Als erste lasse ich mir aktuellen Veränderungen an den von mir beobachteten 
> Artikel listen. Dann sehe ich das wieder Vandalen am Werk waren.

> [die ganze Zeit habe ich mich nicht anmelden müssen, weil meine Zugangsdarten 
> der Klient verwaltet]
 
> Dann schreibe ich noch an einen Absatz weiter. Da zu benutze ich das 
> Rechtschreibprogram meines Klienten und kleine Makros mit ich schneller 
> Tabellen anlegen kann. Meine Vorschau generiert mein Klient mit der Server 
> nicht mit überflüssigen Anfragen belastet wird. 

> Bei dem anderen Edit bin ich mir nicht sicher ob es Cleverer-Nonsis ist oder 
> es sogar Richtig ist. Also markieren, das andere mit besserem Fachwissen die 
> Sache noch mal checken.

> Dann lasse ich mir alle 
> Edits auflisten von der als Vandale markierten IP und gucke was er noch so 
> verzapft hat. 

> Mittlerweile hat ein Admin reagiert und die IP für zwei Stunden ausgesperrt .


Andere Dinge, die du beschreibst, brauchen jedoch Interaktivität, und
ein Netzwerk-Protokoll, das antwortet. Da könntest du mit deinem eigenen
Protokoll recht haben. Aber ich bin mir nicht sicher, ob man dieses
Protokoll mit den eben genannten VCS-Funktionalitäten vermengen sollte.
Die Gefahr ist, dass dabei ein besserer, aber genauso unflexibler
Monolith rauskommt wie beim MediaWiki.

Ein Editor mit Vorschau (oder WYSIWYG), mit sehr leicht bedienbarer
VCS-Funktionalität, wäre nicht nur für Wikis, sondern auch für andere
Dokumentationen, einzelne versionierte Scripte, gemeinsame TODO-Listen,
etc. sinnvoll.

Auch die folgenden drei Ansprüche sehen so aus, als würden sie einen
verbesserten Editor verlangen, aber kein extra Protokoll:

> Bei den 
> einem Edit handelt es sich um eine Anonyme-IP. Die wird von mir dunkelrot 
> gefärbt und als Vandale markiert mit Zeit-Stempel.

> Wenn ich will kann ich mein 
> Klient auch im WYSIWYG-Modus benutzen.

> Zwischenzeitlich werde ich gewahrn, das ich den Abschnitt nicht gesperrt habe 
> für Andere und Versionskonflikte entstehen können. Ich schreibe nur ein paar 
> Zeilen. Da ist das aber nicht nötig. Wenn ich tiefgreifende Änderungen mache, 
> erkennt mein Klient das von selber (kann man einstellen, ab wieviel Zeilen 
> Differenz zur aktuellen Version der Klient die Sperrung des Artikels vom 
> Server automatisch anfordern soll). 


Der Rest sieht mir bei näherer Betrachtung mehr wie ein News-System aus.
Ich meine nicht NNTP, sondern allgemein solche Dinge, die auch in vielen
Webforen, IM, etc. eingebaut werden, und nirgends wirklich ausgereift
sind.

Schafft man es, diese (ich nenne sie mal so) "News"-Features von den
oben genannten "VCS"-Features zu trennen, hätte man etwas viel flexibleres,
von dem man auch außerhalb der Wikis (z.B. Projektmanagement, Groupwares)
profitieren kann.

Folgende von dir beschriebenen Szenarien sind IMHO nicht allzu Wiki-
spezifisch, und könnten Teil eines verbesserten Mail/News/IM/... Protokolls
sein:

> Wenn ich mich in meinen Computer zu hause einlogge, sehe ich in der 
> Start-Leiste ein Button blinken. Denn ohne das ich was aktiv gemacht habe, 
> hat sich der Wiki-Klient beim Server erkundigt, ob Neuigkeiten für mich da 
> sind.

  [Wieso nicht gleich per E-Mail zu dir? Für jede Neuigkeiten-Quelle ein
   extra Programm finde ich nicht erstrebenswert.]

> Wenn ich auf die Diskusionsseiten gehe, sieht das aus wie bei einem (guten) 
> News-Reader. Die Diskusions-Stränge werden automatisch generiert, je nach 
> dem, wer auf was antwortet.

  [Das macht main Mailprogramm doch schon super. Außerdem kann ich dann
   u.U. direkt, persönlich antworten, wenn die Diskussion OT wird.]

> (Die Diskusions-Seiten im Web-Interface bei 
> Wikipedia, sehen größten Teils aus wie "Kraut und Rüben"). 

  [Wiki-Seiten für Diskussionen zu nehmen war eine sehr schlechte
   Idee. Da erkennt man sehr gut die Grenzen eines Wikis. Kurzlebige
   Informationen gehören in ein News-System, langlebige in ein VCS.]

> Die Diskusionens-Beiträge sind unterschiedlich, je nach Autor, bei mir 
> eingefärbt - Je nach seiner Bewertung seiner Arbeit von Andern. Jeder 
> Wiki-Mitarbeiter kann von einem anderen eine Bewertung bekommen (Kompetenz, 
> Konfliktfähigkeit, Kooperationsbereitschaft etc.) So kann ich gleich sehen, 
> ob es Sinn macht mir mit Jemanden eine Redeschlacht zu liefern oder nicht. 
> Ich kann aber auch eine eigene Liste der Personen die ich traue anlegen.

  [Interessantes Feature. Mails und News können dies bereits, wenn auch
   nur begrenzt (Killfiles), einige IM probieren es, viele Webforen
   probieren es, eine gute globale Lösung gab es leider nicht.]

> Mein Klient fragt den Server auch nicht ständig nach Neuigkeiten ab. Alle - 
> sagen wir - 10 Minuten, bestätigt der Klient dem Server, das er noch da ist. 
> Wenn es interessante Neuigkeiten gibt, nimmt der Server Kontakt zu mir auf. 
> Bestätige ich nicht mehr meine Anwesenheit (mit freiem Intervall), wird mein 
> Klient aus der Anwesenheitsliste des Servers gestrichen. Ansonsten werde ich 
> in Echtzeit über aktuelle Ereignisse informiert.

  [Macht dass nicht IMAP so?
   Mail-Benachrichtigungen bei Änderungen können übrigens fast alle VCS.]


Diese Dinge klingen für mich wie ein Mail, News oder IM-Protokoll. Ich schätze,
Jabber und IMAP/SMTP sind davon nicht allzu weit entfernt.

Allgemein fände ich es schön, wenn man auch z.B. per Mailingliste an den
Artikeln mitdiskutieren könnte. Mein Mailclient kann bereits filtern,
Threads anzeigen, etc., und sollte man nicht mit demselben Programm
(meinem Mailclient) sowohl über die BeLUG als auch über Wikipedia-
Artikel diskutieren können?


> So - das kannst du alles *IRGENDWIE* versuchen in HTML/http & CVS rein zu 
> pressen.

Nein, ich will eben nicht alles in ein großes Protokoll pressen. Ich
will kein News-System mit Wiki-Seiten oder Subversion nachbilden.

Ich will *mehrere* Protokolle benutzen, jedes für seinen Zweck. Ich will
eben keine eierlegende Wollmilchsau, egal ob sie nun ein HTTP-basiertes
oder ein selbstentwickeltes Protokoll benutzt.

> Du könntest aber genauso gut das ftp-Protokoll benutzen und ein 
> FTP-Server mit Modulen erweiterbar machen wie Apache und ihn CGI's und PHP 
> aus führen lassen. Oder ein SMTP-, IMAP-, SAMBA-, CUPS-, X11-, DHCP-, NFS-, 
> DNS-,finger-,sunrpc-,nntp-,ntp-, ldap-, ms-sql-s-,  quake-, doom- oder 
> POP3-Protokoll vergewaltigen.

Natürlich nicht. Aber wieso nicht SMTP benutzen, um Artikel-Diskussionen
zu führen? Wieso nicht Jabber oder IMAP benutzen, um Wikipedia-News zu
erhalten? Wieso nicht Subversion oder Mercurial benutzen, um die
Wiki-Seiten zu versionieren und zu verwalten?

> Ich hab schon Server/Clent-Programme geschrieben. Der Aufwand 
> sich ein Protokoll zu überlegen und zu implementieren, ist nach Hinten raus, 
> NICHTS gegen die immer weiter mitgeschleppten Altlasten.

ACK. Aber ich fürchte, du hast meinen Ansatz missverstanden.

Ich will kein News-System auf HTTP aufbauen.

Das einzige, was nett wäre, wäre ein vereinfachtes VCS-Interface, das
auf HTTP aufbaut. Damit man VCS-unabhängig (vielleicht per Browser)
"mal schnell" eine Textdatei weiterbearbeiten kann. Egal, ob es ein
versioniertes Shellscript oder eine Wikiseite ist. Das war alles.

> Auf solche Ideen kommen nur Leute, die über PHP und 
> Javascript nicht hinausgekommen sind und glauben das ein Protokoll was über 
> eine GET-Anfrage hinausgeht unglaublich kompliziert sein muss. 
> 
> Wenn ich nicht bei Null anfangen will, nehme ich SOAP/ssh aber nicht http!

ACK, der "News"-Bereich könnte tatsächlich auch über ssh laufen. Und die
VCS, egal ob CVS, Subversion oder Darcs, tunneln eh schon durch SSH
durch, wenn man will.

Genau darum geht es: Ich will auch nicht bei Null anfangen. Ich
möchte das Problem aufspalten, an geeigneten Grenzen. Dann kann man
die Teilprobleme leichter erschlagen, und diese Teillösungen sind dann
auch für andere Zwecke geeignet, für die man sie nicht verwenden könnte,
wenn alles in einem einzigen großen Protokoll eingewebt wäre.

Ich glaube nicht, dass unsere Ansprüche so grundverschieden sind.
Es sieht eher so aus, als würden uns andere Aspekte an der Wikipedia
stören: Mich stört der Monolith, bestehend aus unflexiblen, nicht
austauschbaren Komponenten. Dich stört das ungeeignete Prokoll, das
effizientes Arbeiten schon im Keim erstickt. Richtig?

Eigentlich ist das die optimale Situation: Zwei sehr unterschiedliche
Ansprüche, aber ein gemeinsames Ziel. Wenn eine Architektur uns beide
zufrieden stimmt, wird sie verdammt gut sein. Deshalb bin ich sehr
gespannt, wie du auf meine Ansprüche und meine Ideen eingehst. Deine
Bedürfnisse haben mich auf jeden Fall nachdenklich gestimmt, und ich
hoffe, dir geht es bei meinen Ideen genauso.


Viele Grüße,

    Volker

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