Bloss eine Idee

[Michael Lackhoff]

Herr Henkel hatte "Bloss eine Idee" und ich muss gestehen, dass 
allegro mich auch immer wieder dazu bringt, Ideen einfach mal 
durchzuspinnen (womit ich selbstverstaendlich nicht Herrn Henkel 
sondern hoechstens mich selbst der Spinnerei verdaechtige).
Und da ich gerade darauf warte, dass ich den naechsten Schritt bei 
einem Sisis-Datenimport endlich endlich anstossen kann (die 
koennen von allegro noch seeeehr viel lernen!) will ich einfach mal 
drauflosspinnen...

Meine Spinnereien drehen sich allerdings meist nicht um das 
Datenformat, das ich ziemlich genial einfach und zugleich 
leistungsfaehig finde. Vielleicht waeren schliessende Tags eine 
Verbesserung, wie Herr Berger meint, wahrscheinlich hat er aber 
auch mit Hans ganz anderen Bedarf als ich mit meinen meist 
einfacheren Datenbanken.
Ich erwische mich vielmehr immer wieder bei Traeumen ueber eine 
Alternative zu dem ganzen Zoo an Sprachen, die sich mittlerweile 
rund um allegro tummeln und damit verbunden der Traum, die 
Klassenbibliothek direkt scripten zu koennen, also mit perl und 
oder python direkt auf einer lebenden Datenbank arbeiten zu 
koennen. 

Ich interpretiere fuer meine Zwecke der Einfachheit halber mal den 
XML-Vorschlag von Herrn Henkel in dem Sinne, dass es auch ihm 
darum geht, an allegro mit Kenntnissen und/oder Tools 
heranzugehen, die nicht hochspezialisiert sind, sondern die sich 
auch sonst (d.h. ausserhalb von allegro) verwenden lassen.
XML ist eben ein Standard, fuer den es immer mehr 
Unterstuetzung aus allen moeglichen Ecken gibt und wenn ich 
sowieso lernen muss, wie man eine DTD schreibt, warum dann 
nicht auch gleich eine allegro-cfg damit bauen?
Bei mir analog: Perl (und z.T. auch Python) brauche ich sowieso 
jeden Tag. Warum nicht gleich meine Datenaufbereitung mit Perl 
machen, statt mich mit den diversen Export- Import- Avanti-Job- 
und A99-Flex mit all ihren Feinheiten und Ausnahmen fuer 
besondere Faelle.
Nicht dass diese Sprachen nicht leistungsfaehig waeren, im 
Gegenteil sie sind extrem effektiv aber leider schwer zu lernen, 
schwer zu lesen und schwer zu pflegen.
Deshalb wohl auch der Wunsch von Herrn Berger:

> Am Rande waere es natuerlich nett, die Exportsprache von allegro
> ueber Bord zu werfen ,vorausgesetzt es gibt etwas
> allgemeingueltigeres, was dasselbe kann... 

Die gaengigen Scriptsprachen sind allgemeingueltig koennen aber 
natuerlich von Haus aus nicht dasselbe. Andererseits koennen Sie 
verhaeltnismaessig leicht ueber Module aufgeruestet werden -- 
durch "normale" Module laesst sich schon sehr viel machen und 
wenn fuer den Rest auch noch ein P*-Wrapper um die 
Klassenbibliothek da waere, oder umgekehrt z.B. Python in A99 
und avanti "embedded" waere, die Moeglichkeiten waeren gar nicht 
auszudenken...

Es stimmt naemlich leider nicht ganz, wenn Herr Hoeppner 
schreibt:

> jemand. Mit avanti habt ihr doch alles, was man für den recht 
> einfachen Zugriff auf eine allegro-Datenbank braucht.

Mit avanti hat man im Moment mindestens eine Sprache mehr, 
naemlich die einschlaegigen allegro-Sprachen _plus_ eine 
Steuersprache (bisher meist Perl, z.B. fuer CGI aber auch Delphi 
oder Python).

Bei anderen Datenbanken gibt es ja auch eine Integration: Bei den 
SQL-Datenbanken gibt es meist entsprechende 
Scriptsprachenmodule, z.T. direkt, z.T. ueber eine 
Zwischenschicht und die andere Alternative kann man z.B. bei MS 
Access sehen, wo eine Scriptsprache (VBA) in das 
Datenbankprogramm integriert wurde. Jedenfalls scheint mir die 
Tendenz ganz klar von programmspezifischen Sprachen weg und 
hin zu allgemein brauchbaren Sprachen mit per Modul zugeladenen 
Sonderfunktionen zu gehen.

Nur um keine falsche Panik aufkommen zu lassen: Es geht mir 
hier nicht um eine "Forderung", sondern ganz im Sinne von Herrn 
Henkel "bloss eine Idee". Vielleicht kann man ja mal in diese 
Richtung weiterdenken. Dass eine entsprechende Version nicht 
kurzfristig aus dem Hut gezaubert werden kann, ist mir schon klar.

Viele Gruesse
Michael Lackhoff

-- 
FH Muenster Bibliothek / EDV
Tel.: 0251/83-64871
FAX: 0251/83-64853