[Allegro] Acon oder Avanti?

[Thomas Berger]

Liebe Frau Koczian,

>>> Da bin ich immer unschlüssig, ob ich einen Avanti-Client schreiben soll
>>> (etwas einfacher zu programmieren) oder lieber Acon ein paarmal aufrufen
>>> (eine Zwischenschicht eingespart). Kann mir jemand mehr Argumente für
>>> das eine oder andere liefern?
>>
>> Kurz: gerade wenn Sie mit objektorientierten Sprachen wie Python oder C#
>> arbeiten, wuerde ich immer in Bausteinen(=Objekten) denken, die sich
>> dann je nach Bedarf zusammenstecken oder auch erweitern lassen, ohne den
>> uebrigen Code zu tangieren.
>>
> Ja, natürlich. Die Frage ist teilweise daraus entstanden, dass es mir bisher
> noch nicht gelungen ist, für Acon und für Avanti Klassen für die Job-Ausführung
> zu basteln, die untereinander 1:1 austauschbar sind. Ein Grund dafür: mir ist
> nicht klar, was Avanti mit den Daten macht, die Acon auf stderr ausgibt. Zur
> Zeit lasse ich Acon in zwei verschiedene Streams schreiben und verarbeite deren
> Inhalt getrennt weiter - und das geht bei Avanti so nicht.
> 
> Aber selbst mit perfekt austauschbaren Acon- und Avanti-Client-Klassen müsste
> ich mich immer noch zwischen ihnen entscheiden ...

"Perfekt" waere fuer mich das Gegenteil: acon bzw. avanti waeren im
Profil so geschaerft, dass sie nicht austauschbar sind.

Was acon bedeutet, ist eigentlich ziemlich klar: Ein Kommandozeilen-
programm zur Selektion und/oder Manipulation von ganzen Datenbanken,
d.h. es hat eine Kommandozeile, kann auf das Dateisystem zugreifen (fuer
Eingangsdaten und/oder Ergebnisse) und - je nach Job mittels "exit" - mit
sehr ausgefeilten Exitcodes operieren. Ziemlich ideal eigentlich fuer
einen Batchbetrieb, konzeptionell eher Overkill, wenn es um das Holen
einzelner Saetze geht. [Die Eigenschaft, dass es ueber das Dateisystem
auch auf die Datenbank zugreift, ist mir allerdings ziemlich egal]

Avanti hat das alles nicht, man kann aber in der Programmiersprache
seiner Wahl etwas zusammenbasteln, das viel davon realisiert, bis
auf die Exitcodes und das Einfangen von STDERR. Ausserdem muss man
Jobs on the fly generieren, denn Eingangsdaten und Kommandozeile
muessen auch in den Job hinein, denn ausser STDIN gibt es ja nichts
und das Dateisystem ist bei so einem Client-Server-Setting m.E.
absolut tabu.

In anderen Settings wuerde man sich eine Vorstellung aufbauen, dass
acon ein High-Level-Client ist, der auf krummen Wegen auf etwas
low-level-Artiges wie avanti zugreifen muss, allegro macht es halt
umgekehrt.

Man koennte sich avanti auch als eine Art Webservice vorstellen,
dummerweise spricht er nicht HTTP und ist auch nicht in der Lage,
Ergebnisse zu verpacken. Derzeit ist avanti eigentlich nichts
weiter als ein komplizierter Emulator fuer ipcopen3()...


viele Gruesse
Thomas Berger