[Allegro] Vorhang noch nicht zu, aber ...

[Bernhard Eversberg]

> Gesendet: Montag, 18. Juli 2016 um 12:17 Uhr
> Von: "Michael Lackhoff" <michael at lackhoff.de>

> Natuerlich
> ist niemand gezwungen, DOS zu benutzen, allerdings sind meiner Erfahrung
> nach diejenigen, die alt genug sind, presto zu beherrschen, damit
> effektiver als mit A99.
Kann sein, daß es einzelne solche Fälle gibt, sie werden aber ganz selten sein.
Ich gehöre nicht dazu. Außerdem hat a99 auch FLEXfreie-Funktionen, die presto
nicht hat.

> Die Abwesenheit von Flex in den DOS-Programmen sehe ich nicht als Nachteil
> sondern als grossen Vorteil. Dass Sie das anders sehen ist klar, aber da
> werden wir wohl nicht mehr auf einen Nenner kommen.

Nicht wirklich. Ihre Sichtweise ist aber auch, auf's Ganze geblickt, etwas zu verengt.
Ich seh natürlich, daß eine FLEX-freie Gesamtlösung von großem Vorteil wäre. 
(Falls sie alles das leisten könnte, was jetzt mittels FLEX realisiert ist.) 
Eine solche Gesamtlösung zu *machen*, das hätte ich mir aber, zugegeben, 
einfach nicht zugetraut. Vor allem nicht für den Windows-Client a99, und der
wurde damals dringend erwartet. Nicht nur das, man mußte auch ganz neuen
Ersatz schaffen für aLF und ORDER und dann ganz neu ZAboM. Gerade für diese
Erweiterungen erwies sich eine mittlere Ebene wie eben FLEX als einzig
realisierbare Lösung. Mit Perl o.a. hätte ich das, wie gesagt nicht hingekriegt,
ich hätte mir zudem das Problem des Versionswechsels von Perl o.a. eingehandelt.
SO blieb alles aus einem Guß und konnte ungestört durch externe Elemente 
kontinuierlich weiterentwickelt werden. Also, das heutige Paket für Windows
ohne FLEX - realistisch betrachtet wirklich undenkbar.

In noch nicht voll ausgebautem Umfang ist doch aber a35 ein Ansatz zu einer 
anderen Lösung. FLEX wird darin im Grunde zurückgedrängt auf ein paar elementare,
standardisierte Routinen, die man als Basis für eine PHP-Umgebung (wie eben
in a35) aber genausogut mit Perl oder Python verwenden könnte: Suchbefehle
ausführen und Ergebnisse liefern, einzene Sätze für Formulare bereitstellen,
Sätze speichern oder löschen, und nur weniges mehr.
Ein so beschaffenes Ensemble könnte ein Anwender dann durchaus als transparentes 
Gesamtkonstrukt ansehen, ohne wissen zu müssen, daß FLEX darin was macht und 
wie es das macht, unabhängig vom Kategorienschema. Im Prinzip wäre mit diesem
Paket immer noch Modifikation und Ausbau auf FLEX-Ebene möglich, also
ohne Eingriff in die C-Programme, aber eben i.d.R. nicht notwendig, sondern man
würde höhere Funktionen eben in PHP o.a. machen, mit einem API für die
Datenbankfunktionen.
Damit könnte man also *browserbasierte* Oberflächen schaffen, und vielleicht
kriege ich sowas auch noch selber hin, die a99 überflüssig machen und damit auch 
dessen, gemäß sauberer Lehre unerwünschbare, FLEX-Erweiterungen.
Momentan ist und bleibt wohl noch länger a99 das meistverwendete Programm, und
dieses wäre, ich wiederhole, nicht darstellbar ohne die FLEX-Ebene. Definitiv.
Anders gesagt,
Ein darüber hinausgehendes, allein in C programmiertes Basispaket zu schaffen, voll
von Perl etc. aus standardisiert ansprechbar, AUCH für Windows-Programme, 
das hätte jedenfalls meine Möglichkeiten überstiegen.
Es gibt aber andere, ich nenne jetzt keine Namen, die das hätten schaffen können, 
und warum auch nicht. Vielleicht sind sogar in der Tat ein oder zwei schon längst 
dabei und haben vor, die Bibliothekswelt in nicht zu ferner Zeit zu überraschen. 
Wäre doch das schönste Ergebnis der OpenSource-Initiative, nein, überhaupt der
ganzen allegro-Initiative.

B.E.