[linux-l] Neuorganisation der Berlinux-Seiten

Volker Grabsch vog at notjusthosting.com
So Nov 20 20:13:38 CET 2005


On Sun, Nov 20, 2005 at 03:10:19PM +0100, Benjamin Schieder wrote:
[SubWiki]
> Das Verzeichnis innerhalb des svn trees ist konfigurierbar. Authentifikation
> existiert nicht, ist ueber apache zu machen bzw. per subversion, diese
> beinhalten bereits hervorragende Mechanismen dafuer.

Hmm, das sieht nur auf den ersten Blick so aus, als wäre es
"naheliegend", aber eigentlich ist es ein großer Umweg.

Ich habe mir gedacht, das CGI-Script verlangt eine Authentifikation
(z.B. per Formular+Cookie), merkt sich Usernamen und Passwort, und
nutzt genau *diese* Infos, um sich gegen den Subversion zu
authentifizieren und die Seiten zu committen.
Ersetzt man Wiki gegen Mailbox und Subversion gegen IMAP, so hat
man dann genau das, was Squirrelmail macht.
Das sollte IMHO das Subwiki-CGI-Script ebenfalls machen.

Wenn das CGI-Script jedoch das Erfassen der Login-Informationen
komplett dem Apache überlässt (via HTTP-Auth), dann kennt es nur
den Usernamen und nicht das Passwort. Aber es muss sich irgendwie
gegen Subversion authentifizieren, d.h. extra für das CGI-Script muss
ein User im Subversion eingerichtet werden, der auf alle Wikiseiten
Schreibzugriff hat. An diese Sch**** haben sich viele Leute dank
MySQL gewöhnt, aber ich finde das weder sicher noch sauber.

> Dokumentation _ist_ spaerlich, aber nach nem Blick ins Konfigurationsfile wird
> das Meiste klar. Stylesheets sind Geschmackssache, ich find die von Wikipedia
> zum K*tzen.

Sie sehen optisch wesentlich besser aus als Subwiki. Was stört dich
denn an ihnen? Trifft deine Kritik auch auf DokuWiki zu? Siehe auch
weiter unten.

Ich finde, ein Wiki steht und fällt mit dem Aussehen der generierten
HTML-Seiten. Sehen sie schlecht aus, gibt es auch weniger Motivation,
sie mit Inhalt zu füllen.

> Fuer statische Seitenerzeugung gibt es auch schon so manche Tools,
> warum das Rad neu erfinden? (und das von mir...)

Klar, manche Tools. Aber *eigentlich* sollten das auch die Wikis
selbst können. Z.B. sollte es IMHO im MediaWiki ein kleines
PHP-Programm geben, das man per Kommandozeile aufruft und welches
einem dann eine (vielleicht auch mehrere) HTML-Seiten generiert.
Einige Konfigurations-Variablen wie z.B. die URL zum Stylesheet
könnten als Parameter kommen.

Genau sowas möchte ich ja gern haben. Dann kann ich diesen Generator
nämlich von einem anderen Wiki aus benutzen (falls es dazu in der
Lage ist), bzw. die Seiten statisch erzeugen.

> > Kurz: Ein Aspekt (das Backend) ist sehr gut gelungen und wunderbar
> > einfach gehalten. Der Rest hakt, wie bei praktisch allen Wikis. Es
> > macht zuviel "selbst", eine noch strengere Aufgabenteilung wäre
> > angebracht.
> 
> Wie jetzt? Erst gibts alles nicht und dann machts doch alles selbst?

Öhhm, bitte lies erstmal:

	http://wikidok.njh6.de/

Es geht darum, dass die Wikis

* einerseits zu *viel* auf einmal machen
  (Versionskontrolle, HTML-Generierung, Webinterface zum Editieren, ..)

* aber andererseits nicht dafür ausgelegt sind, dass man sie nur
  *eine* dieser Tätigkeiten machen lässt
  (d.h. keine wirklich strenge Aufgabenteilung)

Da die Wikis aber immer nur einige Tätigkeiten gut und andere schlecht
machen, ist jedes einzelne uneeignet, und kombinieren kann man sie
nicht.

Das Subwiki hat z.B. ein gutes Webinterface, welches direkt mit
Subversion kommuniziert. Aber die generierten HTML-Seiten sehen
schlecht aus. Das MediaWiki hingegen produziert (IMHO) gut aussehende
Seiten, aber das Backend ist schlecht (selbstgebaute Versionskontrolle
via MySQL).

Würde man das Webinterface (das auf Subversion zugreift) von SubWiki
mit dem HTML-Generator vom MediaWiki verbinden können, hätte man
schon was brauchbares. Nur mal als Beispiel. Stattdessen aber muss
man sich ständig fragen: Nehme ich jetzt das MediaWiki mit den mistigen
MySQL-Tabellen, deren DB-Schema sich alle paar Versionen ändert, oder
nehme ich das SubWiki mit der zu primitiven Wikisprache und den schlecht
aussehenden generierten HTML-Seiten?

Man macht Kompromisse, statt die Vorteile zu kombinieren. So, ich
hoffe, mein Kritikpunkt ist nun klarer geworden.


Übrigens geht mein Wikidok-Projekt noch einen Schritt weiter und will
nicht nur Webinterface, Backend und HTML-Generatoren voneinander
lösen, sondern außerdem noch die Wikisprache vom HTML-Generator. Und
an *der* Stelle geht es nicht mehr "nur" darum, gemeinsame Interfaces
(z.B. über die Kommandozeile) zu gestalten, sondern hier müssten
vielleicht sogar eigene Parser geschrieben werden. Aber das nur am
Rande, *noch* ist nichtmal der erste Schritt nicht getan. Außerdem
wird/wurde das schon in einem anderen Thread diskutiert.


> Ein Beispiel fuer eine ("etwas" gepatchte) Installation von SubWiki findet sich
> hier:
> http://doc.rocklinux.org/

Was genau hast du dort gepatcht? Auf den ersten Blick sehe ich nur einen
etwas anderen Stylesheet.

Außerdem fällt mir auf, dass du in der Tat deine HTML-Seiten *noch*
schlichter gehalten hast. Das hat was, keine Frage. Aber ich (und viele
andere, die ich kenne) mögen es lieber "schick", solange die Ladezeit
nicht zu lang wird.

Mich würde mal interessieren, wieso du diesen Stil bevorzugst. Was
für praktische Vorteile hat das für dich?


Viele Grüße,

	Volker

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



Mehr Informationen über die Mailingliste linux-l