Web Meta Language

[Carola Kummert]

On Tue, 2005-01-18 at 11:36 +0100, Florian Lohoff wrote:
> On Mon, Jan 17, 2005 at 11:04:02PM +0100, Carola Kummert wrote:
> > On Mon, 2005-01-17 at 18:31 +0100, Florian Lohoff wrote:
> > > ich spiele gerade mit dem gedanken ein "mini-wiki" zu bauen was man mit
> > > wenig aufwand mal eben installieren kann (Und nicht gleich
> > > mysql/postgresql oder 1000 files zu bauen).
> > 
> > also das droelfte Wiki-System. Die Dinger gibts irgendwie auch wie Sand
> > am Meer inzwischen ... wer kein Gaestebuch schreibt als
> > Programmieruebung, der macht halt nen Wiki ...
> 
> Der Punkt ist das die Wikis die es gibt entweder voellig ueberladen sind
> (MediaWiki) oder interessante Backends von MySQL, Postgres ueber Oracle
> zu flat file haben ... D.h. ich habe fuer nen dummes wiki mit 20 Pages
> 23 Daemons laufen und/oder interessante apache plugins.

Wieviele Wikis hast du beguckt? Mir fallen aus dem Stand drei Wikis ein,
die mit ein paar Skriptfiles und plaintext-Backend des Weges kommen und
null Demons oder Apache Plugins brauchen. (Okay, Apache sollte ExecCGI
oder nen Modul zum Interpretieren bewusster Sprache haben, sonst ist das
albern.)

> > Btw ist XML als echtes Datenformat beim Verzicht auf nen DB-Backend ne
> > feine Sache, alldieweil das dann problemlos in jedes beliebige
> > Ausgabeformat gestopft werden kann. Bliebe nur noch die Frage, wann man
> > eigentlich parst (bei der Ein- oder der Ausgabe?) und ob es nicht doch
> > sinniger ist, schon mal ueber eine Suchfunktion nachzudenken, damit man
> > seinen Kram auch wiederfindet, sowie ueber nen Cache, damit man nicht
> > jedesmal die Ausgabe prozessieren muss.
> 
> Ziel waere es nur statischen content da liegen zu haben. D.h. das reine
> Browsen fuehrt zu keinen CVS ops oder parsing.

Also Standard-Cache Loesung. Wobei Browsing absolut nichts mit
CVS-Zugriff zu tun hat. Btw sind HTML-Seiten nicht in der Lage, sowas
wie "Edit Wiki Entry" zu handlen. Dafuer brauchts dann doch nen bisserl
mehr Dynamik dahinter. Und SSI ist da die denkbar schlechteste,
unsicherste und inperformanteste Loesung, die es gibt. Aber so weit bist
du in deinen Recherchen inzwischen ja sicher auch gekommen.

> Das bedeuted aber auch
> das neu eingefuegte keywords

s/keywords/Seiten/

btw ist die konsistente Verwaltung von Seitennamen auch bei Aenderung
derselben ueber diverse Wiki-Seiten hinweg das schwierigste Problem. Der
ganze andere Rest ist in nem Nachmittag zwar nicht in schoen aber in
funktionierend runtergeschrieben.

Und noch nen Stichwort: CVS und Dateinamensaenderungen ... irgendwas
klingt hier nach kaputtem Design.

> sofort im CVS angelegt werden muessen
> andernfalls muesste man das ueber den 404 handler machen.

Aeh, Seiten neu anlegen bedeutet nen Change (oder in CVS-Sprache nen add
file; commit -m;). Dass da zusaetzlich noch irgendwo der Kram in einen
Cache (von mir aus halt statisches HTML) gekippt wird, ist ne ganz
andere Kiste.

404 hat damit erstmal noch gar nichts zu tun. Der schlaegt
grundsaetzlich auf, wenn ein Link ins Leere fuehrt. Egal, ob das nun ein
Vertipper war oder eine Seite noch nicht angelegt oder sonstwas.

Im Uebrigen ist es denkbar unguenstig, Seiten bereits dann anzulegen,
wenn sie das erste mal im Wikitext auftauchen. Das fuehrt zu einer Menge
toter/kaputter Eintraege im Backend und spannenden Race Conditions.

Wie auch immer, das wird langsam nen Ausflug in die Spielwiesen des
Applikationsdesigns fuers Web und damit doch eher OT.

Viele Gruesze
Carola 'Sammy' Kummert


-- 
Carola Kummert                 Universitaetsbibliothek Bielefeld
                                    EDV/Anwendungsprogrammierung
kummert at ub.uni-bielefeld.de                    Postfach 10 02 91
+49 521 106-4060                                 33502 Bielefeld