Bloss eine Idee

Do Sep 28 10:10:56 CEST 2000

Lieber Herr Lackhoff, liebe Liste

Natürlich spinne ich auch ein wenig :-)
 Darauf, mit  verbreiteten Tools und Methoden - die man sich im DV-Leben
ohnehin aneignen muß - zu operieren, kam es mir allerdings an.  XML hat für
mich vor allem deshalb eine gewisse Präferenz, weil es nicht nur inhaltlich
für die Darstellung solcher Daten geeignet scheint, wie sie im
Allegro-Alltag anfallen, sondern sich in der inneren Logik weniger als
anderes (z.B. SQL) mit den Allegrogebräuchen, auf die ich nicht verzichten
möchte, beißt.

Aber da wir gerade mal beim Spinnen sind: ich träume z.B. auch davon, eine
Vorrichtung zu haben, mit der man eine Kategorie oder einen Datensatz an
einen Perl-Modul übergeben und die Mächtigkeit dieser Sprache dazu verwenden
kann, den Inhalt zwecks Anzeige zu modifizieren, Indexbegriffe zu bilden
usw. Kurz: Perl sollte die Funktion der Exportsprache übernehmen  und das
Resultat an Allegro zur weiteren Verarbeitung zurückgeben können.

Apropos Perl. Dort ist man ja auch schon eifrig am Werke und schafft mit
Perl::XML eine Schnittstellenbibliothek.

Die Exportsprache, so leistungsfähig und verdienstvoll sie ist, scheint mir
langfristig gerade gewissermaßen ein Klotz am Bein von Allegro zu sein. Sie
ist so originell (wie das meiste aus der unmittelbaren Not der Praxis
geborene), daß sie von allen sonstigen Sprachusancen abweicht, und die
Abweichungen wird ein künftiger Nutzer vielleicht nicht mehr auf sich nehmen
wollen und - da anderes da sein wird, wohl auch nicht mehr müssen. Ich für
mein Teil muß gestehen, daß ich Konsistenz und Kontextunabhängigkeit der
Exportsprache nicht überschaue, und die vielen auch in der Liste
diskutierten Workarounds für die Lösung einzelner Probleme - hinter denen
nolens volens fast immer tagelanges, oft auch ganz stochastisches Probieren
steht - scheint mir immerhin partiell recht zu geben.

Darf ich die Gelegenheit nutzen, noch etwas zu den "bibliothekarischen
Grillen und Finessen" zu sagen, damit die heiligen Kühe etwas von ihrer
vielleicht da und dort so empfundenen Schärfe verlieren?

Ich denke, daß diese Dinge auch einen traditionellen Hintergrund haben.
Wenn man auf handschriftliche Verzeichnisse, Karteikarten usw. angewiesen
ist, bilden sich solche Feinheiten zwangsläufig heraus, um das Aufsuchen der
gewünschten Informationen zu vereinfachen. Man muß angesichts der heute zur
Verfügung stehenden Mittel aber bei jeder einzelnen derselben fragen "wozu
ist sie gut" (das gerät bei Gewöhnung zuweilen in Vergessenheit), "was mag
sich der "Erfinder" dabei gedacht haben" und "braucht man sie angesichts
heutiger Recherchetechniken noch".

Auch möchte ich mich  Ihnen, Herr Lackhoff, ausdrücklich darin anschließen,
daß es gar nicht um "Forderungen" geht. Für mich wenigstens haben
Erörterungen und Diskussionen, die zwar fachbezogen sind, aber doch insofern
unverbindlich, daß nicht heute und morgen ein Termin oder ein Sachzwang
drückt, wo man also auch mal "ins unreine" denken und sprechen kann, wo in
Maßen auch halbgares erlaubt ist um entweder ausgeschieden oder ganz gar
gekocht zu werden, immer einen Entspannungs- und Erholungseffekt, ja selbst
eine versöhnliche Wirkung gegenüber dem täglichene Kleinkram. Ich finde
auch, daß solche
Diskussionen der Liste ganz gut anstehen und einen auflockernden Kontrast zu
"wie mache ich dies mit einem Flex" oder "warum geht jenes nicht, obwohl es
so im Buche steht" bilden.

Gruß
R. Henkel

----- Original Message -----
From: "Michael Lackhoff" <lackhoff at fh-muenster.de>
To: "Diskussionsliste Allegro-C" <allegro at buch.biblio.etc.tu-bs.de>
Sent: Wednesday, September 27, 2000 6:20 PM
Subject: Re: Bloss eine Idee

> 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
>