[Allegro] Zur Zukunft von a30 - PS

[Thomas Berger]

Lieber Herr Eversberg, liebe Liste,

> Aber eben die Wollmilchsau, mit der die klassischen Katalog-
> funktionen zu einer Nebensächlichkeit herabsinken zugunsten
> überlegener Funktionalitäten des Knowledge Engineering, wie das
> nicht nur Bergern vorschwebt, das ist allegro nun mal nicht und schon
> gar nicht seine Web-Schnittstellen.

meine? Mag sein. Egal, ich arbeite dran. "Knowledge Engineering"
habe ich schon lange nicht mehr gehoert und ich erinnere mich auch
nicht mehr daran, was das mal bedeutet haben mag.

Allgemein muss ich allerdings, wen wundert's, widersprechen:
Natuerlich "kann" eine Web-Schnittstelle mehr als die dahinter
liegende Datenbank: Sie macht was damit, liefert Mehrwert.
Z.B. kann man einen Webkatalog mit einer mehrsprachigen Oberflaeche
versehen, obwohl die Datenbank eher einsprachig ist. Oder man
kann, mit ein paar zusaetzlichen externen Dateien (oder einer
Nicht-allegro-Hilfsdatenbank) eine halbwegs vernuenftige, treppchen-
artige Navigation in der Systematik realisieren. Auch neuere
Trends wie facettiertes Browsen sollten moeglich sein (obwohl
avanti mit seinen wohlmeinenden Limits das Leben da schwer macht).

Jedenfalls kann man allegro in solchen Kontexten als Speicher-
und Indexierungsmedium auffassen und ueberlaesst die Aufbereitung
von allem, das ueber Einzeldatensaetze hinausgeht, der Web-
Applikation.

In dem Zusammenhang steht auf meiner (sehr) langfristigen Agenda,
den allmaehlichen Verfall von "avanti" umzukehren: Im Laufe der
Jahre, nach stetem Hin- und Her-Portieren zwischen Win32 und
U**X ist die Sache ja sehr schwerfaellig geworden, auch wenn
moderne Hardware das mehr als wett gemacht hat: Pro Anfrage
erfolgt ja ein Fork (Reaper), dann noch ein Fork fuer eine Shell,
aus dieser dann noch ein Fork fuer ein acon, ist ein Ergebnis
abgeliefert, wird das alles wieder abgebaut. Fuer modernere
Anwendungen benoetigt wird aber ein Antwortverhalten im
einstelligen Millisekundenbereich, d.h. ein Avanti, der
persistente Verbindungen mit seinen Clients aufrecht erhaelt
und seine Datenbankobjekte waehrenddessen behaelt und nachnutzt.
Im derzeitigen Design ist der Steuerungs-Wrapper (die @- und &-
Zeilen um den eigentlichen Job) dabei ein Problem, ich stelle
mir daher eher einen HTTP-Server vor, der den Job per POST
oder GET uebertragen bekommt, wo allegro nun Open Source ist,
sollten sich viele HTTP-Libraries finden lassen, die man sofort
nutzen kann.

viele Gruesse
Thomas Berger