AW: avanti-cl: Programmdatei erneuert

[Volker Bachschneider]

Herr Schmid schrieb:
Nach dem Durchstöbern der verschiedenen C-Quellcodes aus dem Internet fiehl
mir auf, daß diese oft für Input und Output eine eigene Pipe erzeugen, auch
wenn ich bei einem CreatePipe ja schon ein Input- und ein Outputhandle
bekomme. Ich verstehe das zwar noch nicht ganz, aber wenn ich eben auch zwei
getrennte Pipes verwende, funktioniert mein Input nun auch über WriteFile
und ich muß damit nicht mehr eine echte Datei für den Job anlegen. Soweit
sieht avanti-cl wirklich klasse aus!!! Herzlichen Dank.

Sehr geehrter Herr Schmid,

sie erzeugen eine einfache Pipe und die ist halbduplex, d.h. die Daten
fließen immer nur in eine Richtung, hat aber zur allgemeinen Verblüffung
zwei Handles, so daß man anderes vermutet.
Traditionell gibt es dabei die Situation:
Elternprozeß schreibt und Kindprozeß liest:
Dazu muß der Elternprozeß die Leseseite fd[0] stdin und der Kindprozeß die
Schreibseite fd[1] stdout schließen.
Elternprozeß ließt und Kindprozeß schreibt:
Dazu schließt der Elternprozeß fd[1] und der Kindprozeß fd[0]
Wird die Schreibseite geschlossen, steht am Ende der Pipe ein read 0 == EOF
== (/xa1), also quasi AVANTI:EOJ oder AVANTI:EOR nur daß man sich nicht mehr
darum kümmern muß.
Wenn man eine bidirektionale Kommunikation wünscht, generiert man üblicher
Weise zwei Pipes (was sie ja tun) und erzeugt (anders als Herr Höppner
vermutet) danach den Kindprozeß (weil er ja wissen muß woher er konsumiert)
Python fasst das Ganze dann in Funktionen zusammen, die sich fatal ähnlich
sehen os.popen oder win32.popen und beides dann noch hochgenummert bis 4.
Unter Delphi ist die Komponente glaube ich TFileStream (geraten).
Gleichviel, unter Python habe ich noch keine Möglichkeit gefunden, den
Buffer zu beeinflussen, spielt aber vermutlich auch keine Rolle, da es ja
nur um die Blockgröße geht und da ist man 4096 gut bedient, die Dateigröße
verändert sich eh mit dem Absenken und Konsumieren.

Andere Konstruktionen, wie FIFO´s (Named Pipes) oder Sockets haben diese
Einschränkung (halbduplex) nicht, sie unterscheiden aber bekanntlich
zwischen einem Blocking und einem Nonblocking (asynchronen) Mode.

Herr Höppner schlägt nun weiterhin ein Verfahren vor, das sich Message Queue
nennt, mithin eine verkettete Liste die message-Typ, message-Länge und
Message-String mit sich trägt.

Es wird unschädlich sein, das alles zu überlegen, aber schon beim normalen
Avanti habe ich festgestellt, daß Blockgrößen um 2048 - 4096 optimal sind
und der Overhead für andere Strategien zu teuer ist, zumal wir ja mit TCP/IP
handeln. Asynchrones IO bringt deutlich was, aber dazu müßte vermutlich auch
Avanti-cl anders arbeiten und das Verhältnis zwischen Up- und Downstream in
Balance sein.. Bei find beispielsweise verbraucht das Einlesen des Index
gewiß die längste Zeit. Also: kleinere / geteilte Indices == schneller. Und
/ oder zwei Threads einer liest und der andere sucht und schreibt schon mal.
Wenn man sich aber daran gewöhnt hat ist qrix eh der bessere Zugriff.
Apropos Thread´s. Ich habe Avanti-cl mal threaded unter Win98 betrieben. Bis
zu 10 Thread´s (Avanti-cl-Prozeße) ist man immer auf sicheren Seite, ab 40
Thread stirbt mein System. Langlaufende Prozesse  sollte man daher immer
vereinzeln (Gruß an Frau Koczian und ihre Updates).

Die meisten Vorteile verspreche ich mir von Client - AppServer - DBServer -
Konstruktionen (Three Thier Model), wo gewisse Zustände auf dem AppServer
zwischengelagert werden. Also Caching oder vorausschauendes Laden.
Beispielsweise holt man gleich 3 Seiten Registerauszug überträgt aber nur
eine. Das schont Bandbreite etwa bei schmalbandigen Zugängen wie dem
Internet. Überhaupt ist der Bereich von Anwendungen auf der Ebene der
Middleware (AppServer) mit Webservern + PHP o.ä. überhaupt nicht ausgereizt.
Ihre WinClient-Entwicklung finde ich daher sehr begrüßenswert.

Für mich selbst sehe ich einerseits Produktentwicklung für Zope, was sich
mit Avanti-cl jetzt sicherer machen läßt und wir Zope in der Produktion
haben. Andererseits auch Spezialentwicklung auf der Client-Seite, weil ich
mit Bibliothekswesen ja kaum noch etwas zu tun habe und a99 für meine sehr
starren und harten (kritischen) Arbeitsabläufe zu vielseitig ist. Ein
eigenständiger Socketserver auf Medusabasis fällt vielleicht mal im Urlaub
ab. Man sollte auch mal auf die Fortschritte von Twisted schauen. (habe ich
schon länger nicht mehr beobachtet)
Heute habe ich mir mal wxPython angeschaut, eine plattformübergreifene
GUI-Bibliothek. Spannend war dort, das Dialoge (Formulare) aus
XML-Beschreibungen erzeugbar sind. Damit könnte man abhängig von den
ankommenden Allegro-Daten sowas wie adaptive Formulare generieren (nur so
eine Idee). Auch sind die Widget ziemlich reich (HTML, RTF, Formatierter
Text ...). Nur für MDI sehe ich noch nichts (Ist ja auch eine
Windows-Phänomen).

Falls Sie eine Client-Server-Lösung entwickeln fände ich es gut, wenn die
Schnittstellen offengelegt wären. Dann arbeitet man nicht ohne Not doppelt.

Ein Vorschlag / Anregung / Phantasie:
Eine Datenbanknachweisdatenbank (eine Art Namensdienst für Avanti) für
spezielle Clients die direkt auf Internet-Avanti´s zuzugreifen.
Konkret heißt das erstmal: AVANTI:EOJ und AVANTI:EOR würden clientseitig
erstmal bleiben  (sofern der Client Jobs schickt und nicht nur aufruft) und
jeder Anbieter müßte avdemo unter opac/Opac anbieten, damit man mittels help
avaliable die verfügbaren Datenbanken auslesen und auch noch mit dem
klassischen avantis zusammenarbeiten kann. Eine allmählich Migration zu
anderen Lösungen wäre vorzusehen.

Soweit erstmal.
Mit freundlichen Grüßen

Volker Bachschneider

PS: Herr Berger, was sagen Sie denn?