[M] Avanti

[Thomas Berger]

Liebe AllegrologInnen und Allegro-Entwickler,

bislang habe ich nur Trockenuebungen gemacht, daher sind
folgende Anmerkungen zu AVANTI vielleicht nicht sonderlich
relevant:

1.) Die Primaerschluesselproblematik:
    #-@ hat ja eine besondere Bedeutung fuer Indexparameter-
    dateien, weil hier ja der b/B Mechanismus fuer die
    Traverse durch die Hierarchieebenen (auch selbstaendig/
    unselbstaendig) ansetzt.
    Hier sehe ich das Problem (hat nichts mit AVANTI zu
    tun), dass wir uns spaetestens mit einer RAK-Loesung
    fuer unselbstaendige (bislang ja nur Vorschlaege) damit
    auseinandersetzen muessen, dass auch unselbstaendige
    Werke Teile haben, so dass es in Wirklichkeit zwei
    simultane Hierarchien geben kann: Die des Unselbstaendigen
    in sich und diejenige(n) der jeweils enthaltenden Werke.
    Jedenfalls aber sind die bei #-@ gebildeten Schluessel
    stets recht kompliziert, insbesondere wenn sie tatsaechlich
    eindeutig sein sollen (Aufbereitung mit fuehrenden Nullen,
    Strukturerzeugung aus evtl. mehreren Kategorien #00 / #09 /
    #70 / #84 / #708).
    Fuer meinen Geschmack also eignen sich diese "Hierarchie-
    schluessel" nicht besonders gut als Primaerschluessel,
    zumal es ja - zumindest bei eingeschaltetem "Signatur"-
    Generator in der .CFG - einen wirklich eindeutigen,
    wirklich einfachen Schluessel gibt, der ja auch eben
    wegen jenes Signaturgenerators indexiert werden muss.
    Insofern wuerde ich auch fuer AVANTI die UPDATE-Loesung
    vorziehen, naemlich einen (in diesem Fall durch die
    Position seiner ak-Zeile) anderen, benutzerdefinierten
    Schluessel als Primaerschluessel zu verwenden.

2.) PV fuer Avanti (wurde glaube ich schon andiskutiert):
    Gewisse Aufbereitungen erfordern viel Rechenzeit, wenn
    sie jedesmal von der Indexparametrierung gemacht werden
    sollen. Normalerweise kann man sie sehr gut (mittels PV)
    zum Zeitpunkt der Eingabe/Korrektur eines Datensatzes machen,
    Voraussetzung dafuer ist aber manchmal, dass die Datenbank
    zugaenglich ist (etwa automatische Kennzeichnung "falsch"
    verknuepfter Saetze). Fuer die Einmisch-Funktionalitaet von
    AVANTI wuerde ich mir neben der der automatischen Identnummern-
    vergabe so etwas wie die programmierte Validierung wuenschen.
    Ich weiss nicht genau, ob die bisherige (bzw. nur geplante)
    Loesung des Parallelbearbeitens des neuen und des zu
    ersetzenden Datensatzes mit Hilfe der AVANTI-Sprache dieses
    leisten koennte und wenn ja, ob es dann nicht trotzdem
    sehr umstaendlich waere.

3.) Socket-Unterstuetzung: Mir ist klar, dass der derzeitige
    "Kommunikationsmechanismus via Dateisystem", sprich: alle
    beteiligten Programme starren darauf, ob eine bestimmte
    Datei von den jeweils anderen Beteiligten erzeugt wurde,
    auch von der Entwicklungsabteilung nur als Kruecke angesehen
    wird. UNIX und die 32bittigen Windows-Varianten haben ja
    eine (rudimentaere) Socket-Unterstuetzung eingebaut und ich
    plaediere stark dafuer, AVANTI socketfaehig zu machen, auch
    wenn dabei AVANTI fuer DOS-pur fallengelassen werden muss.
    [Auch das Windows-Presto laeuft ja strenggenommen nicht
    unter Windows bzw. WfW 3.11, sondern erst, wenn man die
    Risiken der Installation eines Zusatzproduktes inkauf nimmt...]
    Unter NT haben zwar auch Named Pipes viele der Eigenschaften
    von Sockets, koennen insbesondere auch rechneruebergreifend
    als "Resource" angesprochen werden, das kann aber meines
    Wissens UNIX nicht so gut.

4.) Das letztens beschriebene explizite Einbinden von .cPT's
    unter AVANTI ist meines Erachtens ein Schritt in die
    richtige Richtung: Dateisystemoperationen sind "teuer"
    im Sinne von Performance (nur Kontext-Switching, also das
    Aufstarten neuer Tasks ist noch viel viel teuerer), insofern
    muessen Kopieraktionen (und seien es UNIX-Links) und
    Suchaktionen fuer Parameterdateien auf das absolute Minimum
    beschraenkbar sein!

Viele Gruesse
Thomas Berger