[Allegro] VuFind: Neuer Anlauf

[Thomas Berger]

Lieber Herr Eversberg, liebe Liste,

[ich arbeite die Mails heute irgendwie von hinten nach vorne
ab, aber der Austausch hat ja viele Einzelaspekte aufgeworfen,
hier folgt eine Bemerkung zu einem subjektiv weniger wichtigen]

>> http://svn.gymel.com/acxt/produkt/aconjobdir/
>>
> Ja, das ist äußerst gründlich gedacht und gemacht, keine Frage,
> und nach heutigen Begriffen weitaus akzeptabler als unser
> update.job. Deshalb jedem sehr zu empfehlen, der mit unserem udpate.job
> nicht klarkommt, und wahrscheinlich sollten wir diesen im GP
> durch jenen ersetzen, falls Berger zustimmt. Kleiner Hinweis noch:

Die Zustimmung ist (etwa in Zeile 66 von srch.job) dokumentiert:

// Lizenz:
// GNU GENERAL PUBLIC LICENSE Version 3, 29 June 2007 (cf. GPL.txt) oder neuer
// oder
// Artistic License v2.0 (cf. Artistic-2_0.txt)

(und ich habe darauf geachtet, die Volltexte der Lizenzen in
dasselbe Verzeichnis zu legen)

Mir schienen diese beiden Lizenzen in der Summe alle Anwendungsfaelle
abzudecken (und angeblich sind sie auch miteinander kompatibel),
leider weiss ich nicht, unter welcher Lizenz / welchen Lizenzen
allegro Open Source gehen wird, sollte es dadurch Inkompatiblitaeten
geben, kann ich die Sachen auch gerne anders lizensieren.
Und - das wird oft uebersehen - dass etwas oeffentlich als X lizensiert
ist, hindert den Urheber ja nicht, nach individueller Absprache jemandem
Rechte einzuraeumen, die dieser jemand nach Lizenz X normalerweise nicht
haette.



> Unser update.job ist von Mitte 2008, die $-Variablen gibt es
> in acon aber erst seit Ende 2009. Im Jan. 2010 wurde update.job damit
> ein wenig verbessert, aber nicht umgearbeitet. Denn dann trat der
> Mechanismus in Aktion, der einen zaudern läßt, ein funktionierendes
> Programmgebilde nochmal ganz neu zu schreiben. Vor allem, weil

"Meine" srch.job und update.job benoetigen sogar noch neuere
acon-Versionen (das ist im Dateikopf jeweils dokumentiert).
Ich hatte die Jobs Anfang 2010 oder so von Anwender- auf
$-Variable umgebaut, und weiss jetzt nicht mehr genau, was
noch erforderlich war. Irgendwo gibt es immer eine Grenze,
wo etwas einfach nicht geht: Wir konnten nicht erwarten, dass
die erste Version von acon, die $-Variable konnte, sofort
fehlerfrei war, umgekehrt kann man nicht ewig Ruecksicht auf
diese Ur-Version nehmen, denn die Konsequenz waere, $-Variable
niemals einsetzen zu koennen, da waeren dann alle spaeteren
Korrekturen an acon ueberfluessig gewesen.

Kleinigkeiten lassen sich immer umschiffen, update.job hat
z.B. einige ueber $BUGFIX geleitete Alternativen, um
Problemstellen zu umschiffen, die die angegebenen acon-
Versionen noch haben, aktuell aber behoben sind.



>> Die Seite bietet nicht nur Downloads an, sondern diskutiert auch,
>> wie existierende UPDATE-Aufrufe fuer die Nutzung mit acon
>> umzuwandeln sind
>>
> Auch das verdienstvoll, nur für manchen Leser vermutlich etwas abstrakt.
> Nicht jeder bewegt sich gewohnheitsmäßig auf solchem Niveau.
> Hinsichtlich update ist es einfach so, daß man statt
> 
> update -fm.. -d... ...
> 
> zu schreiben hat:
> 
> acon -jupdate -fm... -d... ...
> 
> also nur das Befehlswort "update" in einem Batch ersetzt durch
> den Ausdruck  "acon -jupdate", wie heute früher schon erklärt.
> Es ist dieser Mangel an Konkretisierung durch simple Beispiele, was
> mich in Ihren ansonsten tadellosen Darstellungen immer mal irritiert.

Zugegebenermassen ist es eine Anleitung fuer die maschinelle
Live-Umstellung vorhandener Aufrufzeilen, aber so einfach, wie
Sie es darstellen, ist es auch nicht (bzw. war es nicht, als ich
den Text das letzte Mal ueberarbeitet habe).

Vorhandene Aufrufe von SRCH.EXE und UPDATE.EXE uebernehmen Werte
fuer die Schalter -P, -d und -k implizit aus dem Environment,
acon benoetigt(e) diese drei jedoch explizit.

D.h. ausser der Ersetzung ...update... durch ...acon -j%-P%\update.job...
muss die vorhandene Kommandozeile untersucht werden und die drei
obigen Schalter sind evtl. zu ergaenzen (nicht einmal beruecksichtigt
dabei ist das Standard-Fallback zu "A" fuer die Konfiguration)

viele Gruesse
Thomas Berger