[Allegro] Vb.211: Mehr Licht, mehr Luft

[Thomas Berger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lieber Herr Eversberg,

> So, jetzt wurden weitere Verfeinerungen vorgenommen, erst mal für Linux,
> so daß avanti und acon jetzt auch mit diesen Situationen klarkommen
> sollten.
> Fuer das Suchen nach der uifsGER gilt diese Reihenfolge:

??? Meine Tests legen nicht wirklich nahe, dass uifsGER in einem
Verzeichnis namens avanti.con gesucht wird ;-)

>> avanti.con
>> avanti.conf

o.k.: Ich kann nun mit dem Verzeichnislayout aus avanti-blabla.tar.gz
und vorherigem Wechsel nach etc die Angelegenheit starten und auch
Jobs ausfuehren.


>> ..\etc\avanti.con
>> ..\etc\avanti.conf
> 
> bezogen auf das Verzeichnis, wo avanti und acon liegen.

Nein, derzeit bezogen auf das Arbeitsverzeichnis (also das
aktuelle Verzeichnis beim Start von avanti, was wenig Sinn macht).
[Ich darf nun also nicht von einem beliebigen Verzeichnis aus starten,
sondern nur von einem parallel zu etc/, da bleibt nur bin/.]

Erzeuge ich allerdings Verzeichnis bla parallel zu etc und starte
avanti, funktioniert dies. Bei einer anschliessenden Recherche findet
acon dann die Datei "UIFS" nicht (obwohl in ../etc, sowohl aus Sicht
des Arbeitsverzeichnisses als aus Sicht des bin-Verzeichnisses).

Fazit: Derzeit kann man also *nur* etc als Startverzeichnis nehmen
(bzw. uifS ins bin-Verzeichnis kopieren, dann kann man auch dort
starten.)

###

Ich habe vorhin einmal acon-Aufrufe unter Win32 ausprobiert
(Layout aus inst-all.exe, d.h. acon.exe und uifsger im Programm-
Verzeichnis), hier ist es ein aehnliches Phaenomen: Wenn ich nicht
das Programmverzeichnis als Arbeitsverzeichnis habe, dann gibt
es eine Fehlermeldung bezueglich UIFS, ausser es gibt diese
Datei in ..\etc relativ zum *Arbeitsverzeichnis*.

Aber selbst, wenn ich sie dorthin lege, funktioniert nichts,
denn der Schalter -P scheint nicht beruecksichtigt zu werden,
jedenfalls beschwert sich acon nun anschliessend ueber eine nicht
gefundene $a.cfg (ausser wiederum das Arbeitsverzeichnis ist
das Programmverzeichnis).

###

Vielleicht waere das die Gelegenheit, einen radikalen Schnitt zu machen:

* uifSger wird im Programmverzeichnis gesucht, das ist bei
  avanti: ausschliesslich das Verzeichnis, in dem avanti liegt
  acon: das Verzeichnis aus dem -P-Schalter (der implizit auf
      das Verzeichnis gesetzt wird, wo avanti liegt, wenn er fehlt)

* avanti.con/conf ist fuer
  avanti zwingend in der Kommandozeile anzugeben (Schalter -f),
         die NT-Service-Installation kann hier ja avanti.con
         aus ../etc eintragen. Unter Unix haette man damit die
         Freiheit, die .con-Datei ins zentrale /etc zu legen,
         oder (je nach Admin-Recht) auch nicht.
  acon: Konfigurationsdatei wird ueberhaupt nicht mehr
        ausgewertet/beruecksichtigt


Damit acon ohne .conf-Datei auskommt, muss avanti folgende Werte
aus der .conf-Datei an acon uebergeben, und acon muss diese implizit
erkennen koennen:

- -b (als "directoryy" "\" "indexparameter", dabei sind die ggfls.
   relativen Pfade aufzuloesen)

- -k (als "konfiguration")

- -a [bestimmt aus der @-Zeile im Job bzw. "access"], optional, Default 0
  Anm.: Der Beispiel-Job "update.job" wuerde also -a1 (oder mehr)
  im Aufruf benoetigen. Wenn ich mich recht erinnere, eroeffnet -a2
  "Zugriff" auf Register 10, und -a3 auf Register 11, wobei "Zugriff"
  m.W. aber nur die Registerauszuege unter direkter Registerangabe
  meint, also "qrix |:..." und "qrix |;..."? Macht das noch Sinn?
  Benoetigt wuerde ja eher, gewisse Kategorien oder Satzarten nicht
  per Pauschalexport "rauszulassen" sowie v.a. gewisse Saetze gegen
  Veraenderung zu schuetzen. Die Einschraenkung auf gewisse .ald-Dateien
  wie bei PRESTO und a99 mit access=1 macht wenig Sinn, das
  Unterdruecken gewisser GUI-Elemente wie bei access=2 ("global"
  nicht erlaubt) ist auf acon nicht uebertragbar.

- -O aus der @-Zeile im Job, optional

- -L (als logfile-Setzung), optional (fehlt es: implizit aus -b bestimmt)
   [Herr Butkus hat nicht verstanden, dass es bei Avanti 1.x "logfile"
   in zwei Bedeutungen gab und daher als Kommentar in die
   [general]-Section der .conf-Datei von Avanti 2.x einen
   datenbankspezifischen Logdateinamen gesetzt. Seitdem versteht es
   niemand mehr bzw. keiner hat je getestet, ob das nicht durcheinander
   geht.


Ausserdem (aber ich halte das aus Sicherheitsgruenden fuer
hoechst problematisch) koennte avanti *vor* dem Aufstarten von acon
das Arbeitsverzeichnis entsprechend der &-Zeile im Job wechseln.
[es gab frueher schon oft die Diskussion, was ein halbwegs
sicherer Kompromiss sein koennte, z.B. alle Pfade in der &-Zeile
als relativ zum Startverzeichnis von avanti auffassen und keine
".."-Konstruktionen zulassen: Dann waeren Wechseleien und
Verzeichniszugriffe effektiv auf den Teilbaum unterhalb einer
definierten Stelle im Dateisystem einschraenkbar.]

Damit sollte alles (und wg. -O: noch viel mehr) abgedeckt sein,
was bislang ueber die .con-Datei kommuniziert wurde, aber wg.
acon als Konsolprogramm inzwischen auch ohne .con-Datei moeglich
geworden ist:

[demo]
directory = ..\share\avanti\avdemo
access = 3 			# Berechtigung der Datenbank 0<= access <= 3
konfiguration = a
indexparameter = cat
# hier folgen die Benuzer: "name=PASSWORD:access"
opac=OPAC:0
master=AVANTI:3
admin=ALLEGRO:2

Alle anderen Angaben aus der [general]-Setzung der .conf-Datei sowie
der symbolische Datenbankname aus der @-Zeile im Job betreffen
sowieso nur avanti als Verwaltungsprozess.


Fuer V29 waere noch zu ueberlegen, ob die -O-Setzung nicht
durch die Flex-Sprache ueberladen werden kann (analog
_psw.flx): Die "User"-Eintraege in der Konfigurationsdatei entspricht
ja eher Anwendungsklassen und nicht realen Benutzern, deren
Kennung und Passwort wird in der Client-Anwendung verifiziert,
die Kennung muesste aber dann mit in den Job und sich etwa
auf die Datumsstempel durchschlagen.

Vorschlag: $@User (kann nur einmal pro Sitzung gesetzt werden, d.h.
  nicht geloescht und nicht neu besetzt). Wird $@User gesetzt, dann
  wird es anstelle des -O-Schalters fuer Datumsstempel und #op
  gelesen.

Ebenfalls koennte man ueber die access-Level von acon nachdenken:
Zeitgemaesser waere ein Schreibschutz von Datensaetzen analog a99
(plus Beruecksichtigung des Nutzernamens), kombiniert mit dem
- -fm-Schalter von update, also
  -axy, dabei
   x=0  keine Modifikation bestehender Saetze
   x=1  Modifikation "eigener" Saetze juenger als 48h
   x=2  Modifikation "eigener" Saetze (s.o.)
[Hm: Hier muesste es Ausnahmen fuer Systemzaehler geben,
Inventarisierung etc. Vermutlich ist die Kennung in #99n/e
nicht wirklich geeignet besser waere ein "Katalogisierungslevel"
im Datensatz. Fuer Web-Anwendungen interessant faende ich aber
ein Feature, wo acon-unterstuetzt etwa nur der eine Datensatz mit dem
Passwort des Benutzers aenderbar ist]
   x=3  Modifikation "aller" Saetze, #99e wird aber analog a99
        getestet
   x=4  Schreiben unter Umgehung des Datumsstempel-Tests erlaubt
   y=0  keine Neusaetze erlaubt (default falls x=0)
   y=1  Neusaetze erlaubt (default falls x != 0)

Noch eine Ueberlegung zu Zugriffsrechten: Clients koennen ja
beliebige Jobs an avanti/acon uebertragen. Analog "Parameterdateien"
waere aber auch denkbar, dass bei einem besonders niedrigen
access-Level nur dem avanti-Server bekannte .job-Dateien
zur Ausfuehrung gelangen duerfen, dafuer koennte man den
include-Mechanismus nutzen: Vom Client uebertragen wird nur
ein Rumpf-Job mit Variablensetzungen und abschliessend einem
include-Befehl (der dann von acon evaluiert wird). Avanti
bereits wuerde sicherstellen, dass der uebertragene Job
diesem extrem einfachen Strickmuster genuegt, ansonsten die
Verarbeitung ablehnen.


viele Gruesse
Thomas Berger


P.S.: acon.rtf scheint veraltet und auch etwas inkonsisten.
Vor allem aber fiel mir auf:

acon <srch.job -ka -dxyz.alg -emarcxml/xyz.xml -s#90 -bc:\allegro\demo2\cat

mag zwar unter Win32 mysterioeserweise funktionieren, das
(naemlich "Argumente" hinter der I/O-Redirektion) ist aber
m.W. unter keiner Shell syntaktisch korrekt. Es muesste
heissen:

acon -ka -dxyz.alg -emarcxml/xyz.xml -s#90 -bc:\allegro\demo2\cat  <srch.job

oder alternativ

type srch.job | acon -ka -dxyz.alg -emarcxml/xyz.xml -s#90
- -bc:\allegro\demo2\cat

Was auch auffiel (wir hatten die Diskussion vor einigen Monaten,
damals mussten -d, -b, -P etc. aber noch von Hand geparst werden):
Die "eingebauten" Kommandozeilenoptionen sollten wie bei den anderen
allegro-Modulen tolerant gegenueber Spatien sein, d.h. es sollte
keinen Unterschied zwischen -bc:\allegro\demo2\cat geben und
- -b c:\allegro\demo2\cat

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBSRDivWITJZieluOzAQL0MwP/bpSOWCFD8ditrzHvzyJEmnykK7Tb8fQD
OfKxJZhFhj/wA4C3t8cs5TtkUEG3IrZoSenPYQZ1a/fXi7z4htgtb18/wfX/Mwfk
ofB6Wn98FqG4qdZEDuBCduUz0N2ITiqp6bBjP0r76rhNn8fdPNML8/+dvGtGwaos
KMAp4wf+TqE=
=Zzic
-----END PGP SIGNATURE-----