[linux-l] Wiki-Grundsatz-Diskusion

[Volker Grabsch]

On Tue, Apr 18, 2006 at 04:40:35PM +0200, Olaf Radicke wrote:
> http://svnbook.red-bean.com/en/1.0/ch06s04.html

Ich habe das Subversion-Buch vor längerer Zeit mit wachsener
Begeisterung vollständig durchgelesen. Und ja, das von dir zitierte
Kapitel habe ich mehrmals gelesen, weil ich eine Apache+mod_dav_svn
Installation auf unserem Server vorgenommen habe.

Was mir aber nicht klar ist: Worauf willst du mit diesem Hinweis
hinaus? Dass Subversion bereits via HTTP ansprechbar ist?

Ich sprach von einem *leichtgewichtigen*, *vcs-unabhängigen* Zugang.
WebDAV zählt für mich nicht dazu.

> Am Montag, 17. April 2006 13:59 schrieb Volker Grabsch:
> [...]
> >    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.
> 
> Aber du willst hoffentlich nicht die 386.357 Artikel von Wikipedia auschecken? 
> Sondern nur die die du brachst oder - ?

Ich will jetzt nicht meine eigenen Zitate hevorkramen, aber ich hatte
bereits eingeräumt, dass das VCS eine selektive Auswahl von Dateien
im Arbeitsverzeichnis ermöglichen sollte.

Der direkte Zugang zum Repository war auch eher für kleinere Sachen
gedacht, in meinem konkreten Fall zur Projekt-Homepage bzw. Programm-
Dokumentation.

Aber auch für die Wikipedia könnte ein großes Arbeitsverzeichnis
hilfreich sein, sei es fürs Backup, DVD-Brennen, oder als Vorbereitung
zum Druck.

> Die Such-Funktion von Wikipedia ist 
> so schon grotten schlecht. (ich suche immer über Google nach 
> Wikipedia-Artikeln). Das würde mit CVS nicht leichter werden.

Ich dachte an *der* Stelle wirklich nicht mehr an CVS.  ;-)

> > 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-
> [...]
> > > Dann lasse ich mir alle
> > > Edits auflisten von der als Vandale markierten IP und gucke was er noch
> > > so verzapft hat.
> 
> Ich wüsste nicht, wie ich das mit CVS machen sollte.

Ich sprach auch von Subversion, nicht von CVS. Ich meinte die Suche,
welche Änderungen ein bestimmten Autor vorgenommen hat. AFAIR ist das
mit Subversion möglich, mit CVS eigentlich auch, dachte ich.

(ich gehe bei einer nativen Unterstützung davon aus, dass die
Subversion-Autor-Einträge in den Logs genau den registrierten
Autoren bzw. deren IPs entsprechen. Ich denke, das ist naheliegend
und so würde es jeder machen, wenn er Subversion als Wikipedia-Backend
betreibt.)

> > > Mittlerweile hat ein Admin reagiert und die IP für zwei Stunden
> > > ausgesperrt .
> 
> Die Rechteverwaltung mit CVS und Subversion ist nur rudimentär vorhanden. Man 
> muss Apache als Server verwenden und mehr Möglichkeiten (bei Subversin) zu 
> bekommen.

Da hast du leider recht. Mit dem Punkt war ich voreilig.

Aber um zur eigentlichen Grundidee zurückzukehren: Wäre es an dieser
Stelle nicht sinnvoller, bessere Autorisierungs-Möglichkeiten in das
VCS zu integrieren? So haben auch noch andere Anwendungen etwas davon,
nicht nur das Wiki.

> > 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.
> 
> Das eine ist das Protokoll das andere die Implementierung.

Ein Protokoll, das "alles" machen will, wird selbst zum Monolith.
Nicht auf Code-Ebene, sondern sogar auf Design-Ebene. Damit ist es
nochmals schwieriger, die (Fehl-)Entwicklung hin zu eierlegenden
Wollmilchsau zu verhindern.

> >   [Das macht main Mailprogramm doch schon super. Außerdem kann ich dann
> >    u.U. direkt, persönlich antworten, wenn die Diskussion OT wird.]
> 
> Du willst die Diskussionen von und über 386.357 Artikel mit Mailing Listen 
> abwickeln. Das wird eine Katastrophe. Wie willst du da die Diskusion über 
> einen Artikel wiederfinden, den du gerade versuchst zu verbessern?

Jeder Artikel ein Thema/Thread/Mailingliste, jenachdem, das lässt sich
doch organisatorisch trennen.

(naja, ist ja nicht jeder. Viele Artikel haben keine Diskussionsseite,
also bezieht sich das nicht auf ca. 390.000, sondern nur auf die
diskussionsbedürftigen von ihnen)

> Willst du 
> wie bei der BeLUG in 12-Monats-Takt immer die gleichen Grundsatzdiskusionen 
> führen, weil sich keiner mehr an was erinnern kann oder will?
> 
> Übungsaufgabe:
> 
> Suchen sie im Mail-Archiv der BeLUG alle Beiträge, die sich mit der Frage 
> beschäftigen "Welche Themen gehören auf dieser Liste?" und formuliere sie 
> oder leiten sie ein Meinungsbild ab.

Gut, dann keine Threads. Dann sollte man die Diskussionen pro Artikel
stärker voneinander trennen, also durch getrennte Listen und Archive.

Aber das sind alles organisatorische Details, über dieselben Probleme
(und noch mehr) müsstest du dir Gedanken machen, wenn du ein eigenens
Wikipedia-Mail-Protokoll hochziehst.

> > 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.
> 
> Ich glaube du trennst noch nicht strikt genug, zwischen Protokoll und 
> Implementierung.

Ein selbstdefiniertes Protokoll hat per se erst einmal keine wirkliche
Trennung. Ob diese tatsächlich machbar ist, zeigt sich erst, wenn es
mehrere Clients bzw. mehrere Server gibt.

Verteilst du z.B. die Artikel-Diskussionen per SMTP/IMAP statt eines
eigenen Protokolls, weißt du, dass es 'zig (wenn nicht gar hunderte)
von Clients dafür gibt, in allen Sorten und Geschmacksrichtungen.

Selbiges für das Backend. Bei Subversion z.B. weißt du schon, dass
jeder deine Programm-Dokumentation nicht nur im Browser, sondern
auch (genau wie den Quellcode) mit seinem svn-client, Tortoise, oder
was immer er bevorzugt, verwalten kann.

Diese Vielfalt musst du erst mühsam aufbauen (falls es überhaupt
möglich ist), wenn du ein Blackbox-Backend hast, an das du nur
über ein selbstdefiniertes Protokoll rankommst.


Vielleicht als Zusammenfassung: Wenn du Protokolle wiederverwendest,
kannst du auch hunderte Clients wiederverwenden.

Ist es denn nicht erstrebenswert, dass man Wiki-Artikel-Diskussionen
in seinem Lieblings-Mailprogramm führen kann? Wie willst du das
erreichen, wenn du einen großen Bogen um SMTP machst?

> > 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.
> 
> Aber von 
> http://svnbook.red-bean.com/en/1.0/ch06s04.html
> Spricht du nicht?

Zum zweiten Mal: Nein, das ist nur Zufall, dass Subversion das kann.
Dieses aufstockte Protokoll-Spektakel hatte ich nicht im Sinn. Das
ist ein hervorragendes Beispiel für etwas, dass ich *nicht* mit
"Vorteile durch Wiederverwendung" meine.

(der einzige handfeste Vorteil ist der, dass man sich das aktuelle
Release per HTTP im Browser ziehen kann ... etwas kümmerlich.
Wird WebDAV+SVN irgendwann Delta.V-Kompatibel, ändert sich das
vielleicht *etwas*, aber mangels guter Clients auch nicht wirklich)

> > 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.
> 
> Für komplexe Suchanfragen ist CVS unbrauchbar. (Nenne mir alle Versionen vom 
> Artikel XY die von der IP 82.85.110.40 bis  IP 82.85.110.65 editiert worden, 
> im Zeitraum von Dann bis Dann, wo mehr als 40 Zeichen verändert wurden.)

Stimmt. Wie das bei Subversion aussieht, weiß ich nicht, aber
wahrscheinlich auch nicht besser. Darauf sind sie leider (noch)
nicht optimiert.

> Mann könnte Subversion MySQL als Backend verwenden lassen und direkt (wenn 
> möglich) per SQL abfragen.

Dann brauchst du permanente Tabellen-Schemas. Prinzipiell ne gute Idee,
aber IMHO nicht realistisch. Es sei denn, man baut extra "Views" ein,
und legt für diese eine bestimmte Struktur fest. Dann könnte das was
dauerhaftes werden.

> Bleibt noch die unbefriedigende 
> Benutzerverwaltung. Apache?

Nee, die müsste dann bei MySQL direkt liegen.

> Was machen wir mit den Diskusionen? 300 000 
> News-Groups, je eine für einen Artikel, auf einem News-Server generieren?

Fände ich gar nicht mal so schlecht. Ich weiß nicht, wie effizient NNTP
ist, aber letztendlich müsstest du diese Masse ja auch bei deinem
eigenen Protokoll irgendwie handhaben.

> Die Echtzeit-Benachrichtigungen per ICQ abwickeln?

Nee, ein System sollte reichen. Und komm mir nicht mit ICQ. Wenn, dann
Jabber :-)

Wie sieht es eigentlich mit SMTP+IMAP aus?

> Wenn du einem Link im Dokument folgst oder Editierst, wer von den Server mach 
> dann die Plausiblitäsprüfung und sorgt für die Konsistenz der Daten?

Sorry, ich versteh grad nicht, was du meinst.

Für die Konsistenz sorgt i.A. das VCS. (egal, ob Subversion oder das
MediaWiki-MySQL-VCS)
Falls du mit Plausiblitätsprüfung die Autorisation meinst, das sollte
ebenfalls beim VCS liegen.


Was mir schon bei der letzten Mail aufgefallen ist: Wahrscheinlich gibt
es wirklich kein existierendes Messanging-Protokoll (SMTP, NNTP, Jabber),
das deinen Ansprüchen genügt. Aber wäre es nicht sinnvoller, diesen Teil
erstmal als reines "verbessertes Messanging-System" aufzurollen, statt
es gleich mit Wiki-Funktionalität zu verquicken und mit VCS-fähigkeiten
zu überladen?

Genauso die Autorisation: Wäre es nicht besser, z.B. Subversion einen
besseren Autorisations-Mechanismus zu verpassen, statt selbst eine
Versionskontrolle hochzuziehen? Die könnte wahrscheinlich viel weniger
als Subversion (nur das, was ein Wiki braucht), aber hätte dafür eine
super Rechteverwaltung.

Dann wären wir wieder genau bei dem, was mich zu stört: Ich habe eine
Programm-Doku, pack ich sie nun in dein Wiki-VCS oder in Subversion?
Das eine hat super Rechteverwaltung, das andere super VCS-Features.
Statt die Vorteile von beidem zu genießen habe ich nur die Wahl des
geringeren Übels.


Viele Grüße,

    Volker

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