[Allegro] acon: include und relative Pfade

[Thomas Berger]

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

Lieber Herr Eversberg,

das include-Makro (eine Anweisung ist es strenggenommen ja nicht) von acon
berechnet Pfade relativ zum aktuellen Arbeitsverzeichnis, insbesondere
wird eine ohne Pfad angegebene include-Datei nur im aktuellen Verzeichnis
gesucht.

Dokumentiert ist in xinclude.rtf "Für avanti  muß  dateiname  auf dem
Arbeitsverzeichnis von  acon  oder darunter liegen.", zu konstatieren
ist allerdings, dass relative Pfade mit "../" auch funktionieren:
Sicherheit ade.

Bei der Einfuehrung des Features schrieben Sie am 14.6.2010 (es dauert
halt immer zu lang, bis das dann ernsthaft umzusetzen versucht wird):
>>>
OK, ist jetzt drin. Berücksichtigt werden kann nur der Startpfad von
acon, denn beim Einlesen des Jobs, wenn eine include-Zeile kommt, weiß
ja acon noch nicht, wo der Datenpfad ist!
<<<

Dass damit das Datenverzeichnis nicht als Ort fuer Include-Dateien
infrage kommt, leuchtet ein. Das Avanti-Arbeitsverzeichnis in
Web-Umgebungen ist ein eher unbekanntes Wesen, das haengt davon
ab, wie der Systemdienst installiert wurde und dafuer gibt es
keine Eroerterungen oder Dokumentation...

Im Licht einer acon-Nutzung als Ersatz fuer SRCH und UPDATE ist das
Arbeitsverzeichnis traditionell moeglichst kein Verzeichnis, in dem
Programmdateien vorgehalten werden, sondern eher eines, wo Ergebnisse
abgelegt werden. In dieser Situation speziell ist auch, dass der Job nicht
ueber STDIN hereinkommt, sondern ueber -j als Datei auf der Kommandozeile
angegeben ist.

Es waere zwar ein ziemlicher Bruch mit der bisherigen Tradition von
Programm-, Arbeits- und Datenverzeichnis, aber bei CSS, XSLT und HTTP
habe ich gute Erfahrungen mit dem dort durchgaengigen Mechanismus
gemacht, dass sich relative Pfade stets auf die Adresse der aktuellen
(einbindenden) Datei beziehen: Ihr Ersteller weiss zwar nie im
Voraus, wohin irgendjemand sie ablegen wird, es kann allerdings
erwartet werden, dass zusammengehoerende Dateien in einem bestimmten,
vom Ersteller vorgegebenen Layout (etwa: alle zusammen in ein
Verzeichnis) abgelegt wurden. (In Java ist es m.E. auch aehnlich,
da gibt es den "ClassPath").

Wenn der einbindende Job ueber STDIN hereinkommt, waere sein Speicherort
dann ganz zwanglos das aktuelle Arbeitsverzeichnis von acon...
Man koennte allerdings auch noch einmal darueber nachdenken, was eigentlich
mit dem "etc"-Verzeichnis der avanti-Installationen intendiert gewesen
ist bzw. ob nicht das Verzeichnis, indem die genutzte avanti.con[f]
liegt, einen konzeptionell guenstigeren Ausgangspunkt fuer relative Pfade
darstellt.

Ein zukuenftiges Problem wird dann die Einbindung von Standard-Includes
sein, ein Job setzt ihre Existenz voraus, sie werden aber separat
installiert / gehoeren zu anderen "Paketen": Hier erfolgt dann normalerweise
absolute Adressierung (als URI), und im Fall von XSLT und anderen gibt
es dann optional den XCatalog-Mechanismus, der diese URIs auf lokale
Speicherorte zurueckbiegen kann. Fuer allegro waere dies alles eher
uebertrieben, man koennte aber ueberlegen, ob absolute Pfade der Form
include /paket/helper.inc
sich nicht auf ein Zentrales Ausgangsverzeichnis (Programmverzeichnis?,
Ort von avanti.con[f]?, ...) beziehen koennten. Ich fuerchte allerdings,
dass Herr Fischer Wert darauf legt, echt absolute Adressierung zu
bekommen, wie in
include //server99/C$/avanti/test.inc

Ich habe den Eindruck, Includes fuer acon-Jobs koennen ein sehr maechtiges
Werkzeug werden und es gibt noch nicht besonders viele davon im produktiven
Einsatz: Die Gelegenheit waere also guenstig, hier einen fuer die Zukunft
tragfaehigen Mechanismus auszudenken.

viele Gruesse
Thomas Berger

P.S.: Wie heissen die Dinger eigentlich: Fuer Flex-Dateien hat sich .inc
als Extension etabliert, Aber Job-Includes sind ja nicht a priori kompatibel
und sollten m.E. etwas abweichend benannt werden: .inj, .jnc, .jinc, .jbinc,
.jobinc, .job.inc, .inc.job ?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iJwEAQECAAYFAk3hGJ0ACgkQYhMlmJ6W47N6DwQAjH3dfJSKf/U3b1IZk0mC8y1k
IWeRjwmRko6oK4jEu8EHJDufW+B3kFqoODWxL5UWVGlE3esHKmwf4InU7iEYT2uR
VmcOSfFgkUOGzvFMfnVZ4KDmkZZEsV7Ik7naaEwsfHP+CT4XpbKeMi3VCJ8B6QLc
WAzcHm3J2CYG+rqKWhs=
=8+aD
-----END PGP SIGNATURE-----