Am Samstag, 27. Januar 2007 01:22 schrieb Martin Preuss: > > Wegen meiner Befürchtung, dass gleichzeitig eine weitere aqbanking-Aktion > > vom Benutzer begonnen werden könnte (was dann die gui1 löschen würde), > > müsste ich das im momentanen gwen3-Zustand mit einem Lock auf App-Seite > > verhindern. > > Ich denke, Du muesstest da auf jeden Fall ein Lock einbauen, denn wenn eine > Aktion vom Benutzer begonnen wird und in einem Fenster auf eine > Benutzereingabe wartet, wurde ja bereits *eine* Instanz von AB_BANKING > initialisiert. Wenn Du nun noch parallel eine weitere Aktion startest, > erzeugst Du ja wieder eine initialisierte Instanz, und das macht AqBanking > derzeit ohnehin nicht mit.
Ok, das ist dann halt unvermeidbar. Wäre schön, wenn's ohne ginge (Beispiel MT940-Datei-Import und HBCI-Abruf), aber wenn das im Moment halt notwendig ist, wird das kommen. > > Das hab ich so noch nicht verstanden; müsstest du ggf. genauer erklären. > [...] > > Ok, also in Deinem Beispiel hattest Du je zwei AB_BANKING-Objekte und > jeweils dazu passende GWEN_GUI-Objekte, die Du daran gekoppelt haben > wolltest. > > Deine Befuerchtung war nun, dass wenn Du eine neue GUI mit > GWEN_Gui_SetGui() setzst, dass dann eine bereits bestehende GUI geloescht > wird. Das passiert aber nicht, denn GWEN_Gui_SetGui() loescht das > GUI-Objekt nicht, es setzt nur einen anderen Pointer. > > Da nun zu jedem Zeitpunkt nur jeweils ein AB_BANKING-Objekt aktiv sein > kann, ist es keine Einschraenkung, wenn nur jeweils ein GWEN_GUI-Objekt > aktiv sein kann, weil *eine* Aktion zu einer Zeit in seiner vollen Laenge > ja auch nur ein GWEN_GUI-Objekt verwendet. > > Wenn Du nun also eine Aktion anfaengst, und waehrenddessen eine andere > Aktion starten willst (waehrend das Fenster der ersten Aktion vom Benutzer > ignoriert wird, wie in Deinem Beispiel), passiert bei GWEN_Gui_SetGui() nur > dies: Es wird in allen folgenden GWEN_Gui_xyz-Aufrufen das neue > GWEN_Gui-Objekt verwendet. Das alte wird aber nicht geloescht! > > Du siehst zwar einen Aufruf von GWEN_Gui_free() in der entsprechenden > Funktion, aber in GWEN_Gui_SetGui() wird vorher GWEN_Gui_Attach() > aufgerufen, womit effektiv der Referenzzaehler erhoeht wird. Damit wird > also das alte GWEN_GUI-Objekt tatsaechlich nur geloescht, wenn Du selber es > im Programm geloescht hast (denn nur dann erreicht der Referenzzaehler den > Wert 0). Tatsächlich? Stimmt, jetzt, wo du mich drauf hinweist, sehe ich auch, dass GWEN_Gui_free() ein reference-counting macht. Entschuldigung, dass ich das übersehen hatte. Allerdings wende ich zu meiner Entlastung ein, dass bisher in gwen/aqbanking praktisch alle Funktionen mit dem Namen *_free() nun gerade *kein* reference-Counting gemacht hatten und ich deswegen innerhalb dieser Funktion auch keines erwartet habe... aber wenn das in GWEN_GUI drin ist, wird das in der Tat nicht gelöscht. Das hatte ich also falsch verstanden. > Sicher, Du bekommst wie oben beschrieben in diesem Fall ohnehin Probleme, > aber das liegt nicht an der API von GWEN_GUI, sondern eben daran, dass wir > derzeit nur ein AB_BANKING-Objekt gleichzeitig aktiv halten koennen. > > Nach meinen Schwierigkeiten heute beim Versuch der Implementierung unserer > Idee vom fruehen Abend denke ich, dass der momentane Ansatz die aktuell > beste Moeglichkeit darstellt. > > Was wir aber jetzt schon anstreben koennen, ist das eine derzeit erlaubt > AB_BANKING-Objekt teilweise schon threadsafe zu machen, so dass man zwar > nur ein Objekt hat, da aber mit mehreren Threads durchgehen kann. > > Mit der GWEN_GUI-API wuerden wir vorerst auch keine Probleme bekommen, wenn > der entsprechende Pointer eine Thread-Variable waere. Dann haette naemlich > jeder Thread sein eigenes GWEN_GUI-Objekt, und koennte somit auch getrennte > Ausgaben machen und all seine Benutzerinteraktion in einer Linie > kanalisieren (d.h. also alle Interaktion, die im Zuge der Aktion eines > Threads noetig wird, wird auch in dem einen Parent ablaufen). Kannst du mir nochmal erklären, was genau du mit "Thread-Variable" meinst? Muss die Applikation da was deklarieren oder betrifft das aqbanking/gwen? > Um mehrere AB_BANKING-Objekte gleichzeitig aktiv zu erlauben, muessten wir > uns ueberlegen, wie man das machen koennte, welche Probleme das derzeit > noch verhindern. Das groesste Problem stellen da momentan die Plugins dar. > Die werden wir grundsaetzlich weiterhin nur statisch verwalten koennen, > weil jedes Plugin eh nur einmal im Prozess vorkommen kann (wegen dlopen). > Was allerdings nicht unbedingt statisch sein muss, sind die von den Plugins > erzeugten Objekte (wie CryptToken, Parser etc). Das andere Problem ist die > Konfiguration, da sehe ich momentan noch keine Loesung :-/ > > Wenn wir nun die Benutzerinteraktion komplett nicht-statisch haben wollen, > muessen wir in der leider ueberwiegenden Mehrzahl der Faelle tatsaechlich > in allen Funktionen, die Interaktion machen (ob nun direkt oder indirekt), > den Pointer auf das zu verwendende GUI-Objekt als Argument mitgeben. > > Wie ich naemlich bei Libchipcard festellen musste, reicht es z.B. bei den > Sockets nicht, das GUI-Objekt im Konstruktor zu benennen. Das trifft umso > mehr fuer Sockets zu, die im Listening-Modus sind und zudem bei accept() > selber einen Socket erzeugen... > > Die Sockets sind da nicht das einzige Problem, denn Sockets werden ja nicht > direkt benutzt, sondern ueber GWEN_NetLayer(). Diese muessten also auch in > den Funktionen, die Interaktion ausloesen koennen, einen GUI-Pointer > mitbekommen. > > Letztlich kann das ziemliche Ausmasse annehmen. In Libchipcard habe ich > aufgehoert, als absehbar war, dass jede diesbezuegliche Funktion der > Libchipcard-API einen solchen Pointer haben muesste. Ok. Wenn du nun gerade in libchipcard definitiv sagst, dass das (wegen sockets etc) praktisch unmöglich ist, das GUI-callback-Objekt nicht-statisch einzubauen, dann seh ich das für diesen Bereich ein. Trotzdem würd ich vorschlagen, ob das nicht für andere Teilbereiche nicht-statisch realisiert werden könnte. Prominentes Beispiel wäre eben das "MT940-Datei-Import" in aqbanking, welches ja ein vollwertiges AB_BANKING-Objekt benötigt, aber vom tatsächlichen Ablauf her IIRC wirklich nicht mit anderen Aktionen interferieren dürfte. Mir wäre es deshalb wichtig, ob aqbanking/gwen eigentlich als Ziel anstreben würde, in GUI-Hinsicht thread-safe zu werden (und static GUI-Objekte zu vermeiden), aber dann eben als *Ausnahme* dieses an mehreren Stellen nicht bieten kann, weil's zu schwierig wird in der Implementierung (libchipcard). Bei libchipcard seh ich die Situation von der Natur der Sache her schon näher an einer static-Variable: Du hast da nur *einen* chipcard-Daemon, was also schon mal eine ganz andere Situation als bei Datei-Import oder RDH-keyfile-Aktionen ist. Aber deshalb fände ich es wesentlich besser, wenn als Ultimativ-Ziel eigentlich schon eine GUI-thread-safety erklärt würde, aber lediglich für die libchipcard-Sachen dies halt jetzt nicht so erreichbar ist. Re parallele AB_BANKING-Objekte und Konfiguration: Wie gesagt: Mein Beispiel ist einerseits MT940-Import und andererseits HBCI-Download parallel. Der Import ändert IIRC an der Konfiguration nichts. Von daher fände ich es gut, wenn zumindest diese Sachen parallel zu den anderen erlaubt sein würden. (In gnucash hat das ja durchaus einen realen Hintergrund, gerade in Hinsicht auf die Frage, ob der dort existierende generische OFX- oder sogar QIF-Datei-Import langfristig über aqbanking abgewickelt werden könnte.) Ich fände es also völlig vertretbar, wenn AB_Banking_ExecuteJobs ein GUI-Objekt annehmen würde und in der Doku erklären würde "If this job involves the aqhbci backend"/"If this job involves the libchipcard parts of the aqhbci backend, the GWEN_GUI Objekt *must* be identical to the static GWEN_GUI object as set through GWEN_Gui_SetGui... If this job involves *only* the imexporter plugin xy, the GUI object is allowed to be different from the static GWEN_GUI object..." Oder irgendwie so. Gruß Christian ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Aqbanking-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/aqbanking-devel
