[linux-l] Re: Dateisystem als Datenbank

[Volker Grabsch]

On Tue, Oct 18, 2005 at 04:15:57PM +0200, Oliver Bandel wrote:
> > 	https://dev.njh6.de/wiki/index.php?title=Wikidok
> 
> Wenn das der selbe Link ist, den Du letztens mal geschickt hast...
> ...dann folgendes Feedback: Da steht zwar, was alles Mist ist,
> aber was Du wirklich besser machen willst, oder WIE, das habe ich
> aus den Seiten nicht erkennen können.

Also der Text besteht aus zwei Aufzähungen: Eine, wo ich die Probleme
aufzähle, und einen anderen, wo ich die Architektur meines Lösungs-
ansatzes beschreibe.

Wenn du zweite Liste nicht liest, dafür kann ich nichts.  ;-)

> Und: Ich habe es erst mal nur überflogen, dann aber nochmal gelesen,
> und ich glaube, sogar noch ein drittes mal, aber mir erschloß
> sich der Sinn nicht so recht.
> So frage ich denn: Was soll es mit diesem Projekt auf sich haben?
> Was willst Du verbessern?

Ich will sämtliche in der ersten Liste beschriebenen Misstände
abschaffen.

Sämtliche Grundbausteine, wie Wikisprachen, Datenbanken,
Versionskontrollen, Wiki-Webinterfaces, Stylesheets, etc. gibt es
ja schon in irgendeiner Form, aber nichts davon kann man wirklich
wiederverwenden.

Es geht also weder um eine neue Wiki-Sprache, noch um eine neue
Versionskontrolle, etc. ... Nein, es geht bei mir um die Architektur!
Es geht darum, dass wenn *einer* einen besseren Stylesheet (d.h.
HTML-Export) hat, *alle* Wiki-Sprachen davon profitieren sollten.
Das ist derzeitig nicht möglich, weil die Wikis alles selbst machen,
auf Biegen und Brechen. Auch wenn die Wikis recht klein sind, sind
sind es allesamt "Monolithen" ... und OpenOffice etc. erst recht.

Die Wiederverwendbarkeit von Stylesheets kann aber nur durch saubere
Trennung von Inhalt und Form erreicht werden. Das ist ein ein wichtiges
Teilziel. Das interne Wiki-Format (das XML-Format) wird also keine
Information z.B. über die Dicke einer Tabellen-Trennlinie haben. Und
diesen Mist haben sich die Dokumente einfach nicht zu kümmmern.
Bisherige Wikisprachen müssen also abgespeckt werden, was aber IMHO
kein Nachteil ist, sondern eher ein Vorteil.

Roccos Projekt geht in die Richtung. Wenn er wirklich das gleiche
Ziel hat wie ich, dann schau doch mal in sein "horst". Ich hab's mir
noch nicht angesehen, aber vielleicht werden dir meine Gedanken klarer,
wenn du sein Projekt siehst.

> Soll es eine andere Eingabesprachen  werden?
> Obwohl Du Dich in Diskussionen mit mir oft als XML-Apologet
> betätigt hast,

Dann hast du mich falsch verstanden.

In der Python-NG ist es übrigens andersrum: Da wurde ich zunächst
als XML-Hasser abgestempelt, und nach und nach konnte ich den
Leuten klar machen, dass ich XML nicht grundsätzlich ablehne.
In dieser Liste scheint das Phänomen genau andersrum zu sein.

Beide Listen haben gemeinsam, dass ich in eine Schublade gesteckt
werde, bloß weil ich meine Meinung vertrete. Ich hasse sowas. :-(

> wetterst Du auf den Projekt-Seiten ebenso gegen XML,
> weil es zu verbose ist... (ist nämlich auch bei mir oft
> der Grund, wieso ich dann was spezielles liebr habe).

Meine Güte, diese Sache habe ich hier schon mindestens zweimal
durchgekaut, also nochmal extra für dich:

Das, was *intern* verarbeitet wird, sollte XML sein, da kommen
die XML-Vorteile gut zum Tragen.

Das, was man *im Editor* eintippen muss, sollte lieber kein XML
sein, weil man sich nen Wolf schreibt, und zur Belohnung einen
undurchsichtigen Quelltext erhält. Da dann doch lieber eine Wiki-
Sprache.

Vielleicht wird das klarer, wenn ich mal dazu komme, dort die
versprochene Übersichtsgrafik der Formate anzubringen. Hier
schonmal ein "Preview" in ASCII-Art, der die Sache hoffentlich
etwas klarer erscheinen lässt:


Wikisprache1\                          HTML
Wikisprache2 >  <==>  XML-Format  ==>  DocBook ==> ...
Wikisprache3/                          LaTeX   ==> PDF, ...


> > habe ich mit der Implementierung noch nicht
> > begonnen. Noch nicht alle Specs habe ich ins Wiki gestellt
> 
> Ach so.
> Vielleicht weiß ich deshalb nich genau, was das Projekt erreichen soll...

Das Projekt soll ein Filtersystem bereitstellen, also das, was
in obiger Skizze vereinfacht durch breite Pfeile dargestellt ist.

Weiterhin soll es das zentrale XML-Format entwickeln, obwohl ich
dort schon die meiste Vorarbeit geleistet habe (nur noch nicht
hochgeladen). Dieses Format soll auf der einen Seite mehr abdecken
als bisherige Doksysteme, z.B. auch direkte Elemente von Baumstrukturen,
nicht nur von verschachtelten Listen (obwohl die Syntax natürlich
fast dieselbe ist). Auf der anderen Seite wird es weniger abdecken,
nämlich auf stilistische Details verzichten, und Sachen wie "beliebigen
HTML / LaTeX / ... - Code einbetten" wird es niemals geben.


> Wenn Du eine spezielle Fiulter-Funktionalität haben willst,
> macht es Sinn, eine DSL genau für diesen Zweck zu schreiben.

Och mann, schreib ich hier etwa so zweideutig? Ich meine .. ja, das
Wort "Filter" hat mehrere Bedeutungen, aber wird aus dem Kontext nicht
klar, dass ich hier lediglich Filter im klassischen Unix-Sinn meine?

Mit Filtersystem meine ich mehrere Programme, die von Dateien / Stdin
lesen und in Dateien / Stdout schreiben, und dabei z.B. Wikisprache1
ins das Wiki-XML-Format übersetzen, oder das XML-Format nach LaTeX, ...
*Das* meine ich mit Filtersystem.

> [...]
> > Wenn also jemand Lust hat ... noch ist das Projekt nicht gestartet.
> 
> Gibt es Vorgaben zur Implementationssprache? ;-)

Nein, wiegesagt. Aber sie sollten nicht zu kompliziert sein.

Zum Beispiel wäre für das Umwandeln des Wiki-XML-Formats nach
(X)HTML wohl ein XSLT-Stylesheet am besten.

Für die Kontertierungen MediaWiki <-> WikiXML-Format hingegen
wäre wohl PHP ziemlich geeignet, um den MediaWiki-Code (insbesondere
den Parse-Code) wiederverwenden zu können.

Oder auch Python+PyParser oder das Ocaml+Lex/Yacc, wenn man die
Parser per Hand schreibt. Hier suche ich selbst noch nach praktikablen
Lösungen.

Und es sollte nicht zu exostische Sachen benötigen, also um mal
ein einfaches Kriterum zu nennen: Mit den bei Debian/Sarge 3.1
mitgelieferten Paketen sollte es auskommen.


Viele Grüße,

	Volker

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