Moin Martin, Martin Preuss schrieb: > On Donnerstag, 19. Juni 2008, Micha Lenk wrote: >> [...] Allerdings sehe ich es genauso als Aufgabe der >> AqBanking-Bibliothek, die (veraltete) Konfiguration zu parsen. Insofern >> wäre es sehr geschickt, wenn AqBanking zumindest etwas mehr >> Unterstützung anbietet, die Konfiguration von einem alten Pfad zu lesen >> (gibt es schon, in dem man einfach einen anderen Pfad in >> AB_Banking_new() angibt), und diese dann in einem neuen Pfad zu >> schreiben (gibt es noch nicht). > [...] > > Also, AqBanking parsed natuerlich auch aeltere Konfigurationen, und zwar > ziemlich weit zurueck. Aber wie ich beschrieben habe, haengt es sehr vom > Benutzer bzw. der jeweiligen Anwendung ab, was hier genau gemacht werden > muss.
Ja, das Parsen der AqBanking-Konfiguration (.aqbanking/settings.conf) sieht doch aber immer gleich aus und ist auch eigentlich *immer* erforderlich. Wie ich schon schrieb: Es klappt ja auch wunderbar, eine alte AqBanking-Konfiguration einzulesen. Aber dann ist man derzeit dazu verdonnert, den Speicherort der alten AqBanking-Konfiguration auch weiter zu verwenden. Und genau davon rätst du ja (in der Antwort auf Manfreds Vorschlag, das Verzeichnis .banking einfach weiter zu verwenden) ab. > Im einfachsten Fall reicht ein "cp". In anderen Faellen aber unter Umstaenden > nicht. Nun habe ich die Wahl: Baue ich mit nicht unerheblichem Aufwand eine > Funktion ein, die selbstaendig bzw. mit Benutzerinteraktion ermittelt, ob und > was kopiert werden soll, oder ueberlasse ich das dem Benutzer? Es geht garnicht so sehr darum, dass da groß Benutzer-Interaktion vom AqBanking generiert wird, sondern mehr darum, die einzelnen Bausteine für die Benutzerinteraktion zur Verfügung zu stellen. Z. B. Konfiguration aus Pfad A lesen und Konfiguration nach Pfad B schreiben. Ein stumpfes "cp -a" zu machen, halte ich eigentlich sowieso für einen eher mittelprächtigen Ansatz. > [...] > Auch, wenn ich mich wiederhole (wir hatten diese Diskussion doch schon): > Mein .aqbanking-Verzeichnis hat inzwischen eine Groesse von 50MB. Ich wuerde > nicht wollen, dass AqBanking das waehrend des Aufrufes von AB_Banking_Init() > oder _InitOnline() mal eben so kopiert. Ich auch nicht. Aber da musst du mich auch falsch verstanden haben. Ich habe akzeptiert, dass in AB_Banking_Init*() keine Benutzer-Interaktion passierenn wird. Und ein Kopieren von Daten dieser Größenordnung sollte tatsächlich nur mit Wissen des Benutzers passieren. >> Ich habe mal versucht, eine Funktion AB_Banking_SetUserDataDir >> hinzuzufügen (siehe Patch im Anhang), die von einer Anwendung genutzt >> werden könnte. Aber anscheinend kriegen die Backends nix vom geänderten >> dataDir mit: Nach einem anschließenden AB_Banking_Save() hat AqBanking > [...] > > Das wuerde ich so aber auch nicht aufnehmen koennen: AqBanking ist bisher > darauf angelegt, dass der Datenpfad zu Beginn festgelegt wird (im > Konstruktor). Beim Initialisieren holen sich u.a. die Backends (aber auch > eventuell andere Plugins, und spaeter die Anwendung) diesen Pfad und > erweitern ihn um ihre Unterverzeichnisse. Da bekommen die nicht mit, wenn man > AqBanking ploetzlich das Verzeichnis unter dem Hintern wegzieht (sprich: Das > Verzeichnis aendert). Das habe ich ja durchaus schon festgestellt. Die Frage ist bloß, ob das so bleiben muss. Ich bin ja durchaus bereit, in entsprechende Änderungen auch Arbeit zu investieren -- zumindest wenn du erkennen lässt, dass das eine akzeptable Änderung wäre. Eine gänzlich andere Idee wäre, eine Funktion AB_Banking_Save(path) hinzuzufügen, der man einen neuen Pfad übergeben könnte. Ich vermute jedoch, dass im Endeffekt die zu machende Arbeit an den Backends die selbe ist. > [...] >> Es geht mir ja erstmal nur darum, dass eine vorhandene und >> funktionierende Konfiguration (d. h. auch alle Konten) nicht einfach so >> flöten geht. Den ganzen anderen Rest (Logfiles usw.) würde ich erstmal >> ignorieren. Und wenn die Anwendung noch andere Daten retten will, ist >> das natürlich ihr überlassen, wie sie das macht. > [...] > > Von wegen: Da geht doch die Inkonsistenz schon los. Wie sollte AqBanking von > sich aus entscheiden, welche Daten kopiert werden sollen und welche nicht? Es dürfte doch relativ klar sein, auf welche Dateien AB_Banking_Init() und AB_Banking_OnlineInit() zugreift. Oder etwa nicht? > [...] > Ich finde, der Aufwand sollte zum Nutzen schon in einem gesunden Verhaeltnis > stehen. Und wenn der Benutzer lediglich einen einfachen Befehl eingeben muss > (und der Power-User das detaillierter regeln kann), sollte nicht aufwaendige > Logik in AqBanking eingebaut werden, die darueber hinaus nur ein einziges Mal > aufgerufen wird. Mit diesem Argument dürftest du eigentlich auch keine Funktionalität für das Erstellen von HBCI-Schlüsseln u. ä. anbieten: Die Leute können doch genau so gut etwas Zufall zusammenwürfeln und 'nen Hex-Editor benutzen. Das müssen die Nutzer doch auch nur einmal machen... Benutzbarkeit *ist* ein Faktor, der maßgeblich ist, ob sich ein Programm bei den Nutzern durchsetzt oder nicht. Momentan hat AqBanking nicht all zu viel Konkurrenz (dazu tragen auch die schlecht zugänglichen Spezifikationen bei), so dass viele Nutzer mangels Alternativen auf AqBanking angewiesen sind. Das ist aber kein Grund, sich bei solchen Problemen zurückzulehnen und die Nutzer auf die Kommandozeile zu verweisen. Es fordert ja niemand, dass *du* die ganze Arbeit machst. Aber manchmal ist es echt anstrengend, sogar nur konstruktive Vorschläge zu machen. Schöne Grüße Micha ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Aqbanking-devel mailing list Aqbanking-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/aqbanking-devel
