[Allegro] Hat Allegro den Ruf der Antiquiertheit?

[Roland Henkel]

Liebe Listenleser,


Ein paar Dinge müchte ich, wenn auch eher als Zukunftsmusik oder 
Anregung zur Diskussion beisteuern.

Zunächst: An der Datenbank gibt es, ausser der aus meiner Sicht 
überfälligen vollständigen UTF-8 Fähigkeit nichts auszusetzen.
Lesen/Speichern der Daten ist performant, die Indizes hilfreich und wer
sich mit Zwischentabellen und ähnlichem in SQL auskennt, weiß auch die
Möglichkeit der Mehrfach- oder Folgekategorien zu schätzen.

(Nebenbei: Dass SQL "langsam" sei, ist mindest genau so eine tradierte 
Sage wie die, dass allegro antiquiert ist :-). In dieser Totalität 
stimmt weder das eine noch das andere.)

Die Vorschläge und Ideen der Vorredner will ich hier nicht wiederholen, 
  ich stimme mit ihnen weitgehend überein.

Was ich mittelfristig gut finden würde, wäre

1. Einfrierung der Desktopversion und volle Konzentration auf die 
Serverseite.
Für die Desktopnutzung kann man eine Standardanwendung und einen kleinen 
eingebauten Webserver mitliefern, wie man ihn heute bei etlichen 
Anwendungen mitbekommt.

Auch die Möglichkleit, statt eines eigenen Avanti-Servers ein mod_avanti
zu erfinden, scheint mir nicht völlig abwegig.

2. Umstellung der Konfiguration auf XML.
Das ist weniger der Mode geschuldet als der Vorstellung, dass eine 
solche Konfiguration auch von Fremdanwendungen ausgelesen werden könnte 
     und entsprechend der Angaben sozusagen wüßte, womit sie es zu tun 
hat und sich entsprechend selber konfigurieren könnte.

Diese Konfiguration könnte als Schema oder DTD dann auch die Kategorien 
beschreiben und ihre Evaluierung ermöglichen.

3. Anpassung der Zeichenkettensyntax an das übliche (\r, \n, \s \xnn, 
\onn usw. und Backslash als Fluchtsymbol) keine Sonderbedeutung 
irgendwelcher Zeichen und Zeichenkombinationen

4. Zusammenführung von FLEX und avanti-Befehlen zu einer konsistenten 
und flexiblen Abfragesprache, die auch Rekursionen usw. ermöglicht und 
die es erlaubt, sich aus den Sprachelementen eben das zusammenzubauen, 
was man gerade braucht.

Eine solche Abfragesprache müsste sowohl Funktionen für den Index (z.b. 
blättern, an einer bestimtmen Stelle positionieren usw.) als auch für 
die Datensätze einschliesen. Auch Volltextsuche unter Umgehung der 
Indizes sollte möglich sein.

Die Flexe in allen Ehren, aber mir kommt vor, als ob sie zu 
funktionsgebunden und kontextbehaftet sind. Wenn mal wieder eine 
Funktionalität gebraucht wird, wird rasch ein neuer Flex geschrieben.
Man müsste sich aber benötigte Funktionalitäten aus dem Sprachvorrat der 
Abfragesprache selber schreiben können.

Das bisherige Verfahren führt m.E. im Laufe der Zeit dazu, dass sich 
einzelne Flexe in ihren Funktionen teilweise überlappen, dass ein ein 
Namenswirrwarr entsteht (Find find f1nd) und dass man für spezielle 
Dinge dann doch wieder nach Provisorien und Workarounds  suchen nuss.


5. Es ist m.E. nicht die Aufgabe eines Servers, Daten bereits in 
irgendeiner vorformatierten Form zu liefern. Das kann - oft eleganter 
und flexibler - die jeweilig angewendete Webscriptsprache erledigen. Der 
Server (nicht erst phpac oder ähnliches) sollte sich darauf beschränken, 
auf eine Abfrage in die zutreffenden Datensätze in einer definierten 
"Raw"-Form zu liefern, also etwa als Hash mit den Kategorienummern als 
Schlüssel.

6. Statt Exportsprache u.ä. könnten bei einem serverzentrierten Ansatz, 
wie ich ihn hier zu beschreiben versuche, sofern überhaupt noch im 
selben Maße gebraucht (denn was sollte mich hindern, einen Datensatz, 
den ich als Hash vom Server bekomme, mittels PHP, Java oder sonst etwas 
in jede beliebige Ausgabe zu transformieren?) Funktionen, Klassen, 
Interfaces bereitgestellt werden. Vielleicht würde auch ein XML-Export 
als Lingua Franca in der Zukunft genügen.

Das scripting wäre mit anderen Worten vollständig der jeweiligen 
Webentwicklungsumgebung überlassen, was vielleicht doch auch eine 
Entlastung der Entwicklungsabteilung mit sich bringen würde. Diese hätte 
sich "nur noch" um die Funktionstüchtigkeit des Servers und seiner 
Anschlusstellen zu kümmern.


Nutzerseitig scheint es mir gleichgültig, ob einer für eine 
Allegro-Anwendung PHP (z.B)  oder die Exportsprache lernen müßte.
Ersteres dürfe allerdings mehr Vergnügen machen :-) und das erworbene 
Wissen wäre auch anderweitig brauchbar.

7. All die bibliothekarischen Einzelanwendungen wie Ausleihverbuchung 
könnten dann um den Server und seiner Anschlussstellen herum von beinahe 
jedermann entwickelt werden, was nicht ausschließt, dass die 
Entwicklungsabteilung Standardmodule dafür bereit stellt.



Das sind natürlich Ideen, die sich fürs Wochenende eignen und nicht als
Wunsch oder gar Forderung, sondern als Anregung gemeint sind.


Herr Lehmann hat ja recht, wenn er meint, dass sich Allegro bewegen 
müsse. Immer mal wieder ein neuer Flex, ein Workaround, ein Trick kann 
auf die Dauer nicht die Lösung sein. Zu befürchten ist eher, dass unter 
dem Anschein momentaner Verbesserung das ganze so zementiert wird, das 
"Bewegung" immer schwerer wird.


Mit freundlichen Grüssen
R. Henkel