Moin, On Freitag, 20. Juni 2008, Micha Lenk wrote: [...] > 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. [...]
Es ist aber bei einem vollstaendigen Wechsel von AqBanking2 zu 3 ein sinnvoller Vorgang. Denn zumindest in QBankManager verwende ich alle meine Daten aus der alten Konfiguration weiter. Aber AqBanking ist da abstrakt: Es stellt Informationen darueber zur Verfuegung, wie die Standard-Pfade sind, aber es weiss nicht, welches Backend und/oder Plugin welche Daten wohin schreibt. Das bedeutet also, AqBanking kann Dir nicht mehr Info geben als die Pfade, und die kennst Du inzwischen: $HOME/.banking beim alten AqBanking2, und $HOME/.aqbanking beim neuen. Andernfalls muesste ich also einbauen, dass die Plugins selber auch noch mal nachfragen, welche Dateien kopiert werden sollen (z.B. Logs). Das alles einzubauen, nur um dem Benutzer oder Anwendungs-Programmierer das "cp" zu ersparen (bzw. ein passendes Aequivalent), halte ich fuer nicht vertretbar. Das Problem liesse sich ganz einfach dadurch loesen, dass die Anwendung diese Daten nach Interaktion mit dem Benutzer kopiert. Sie weiss, ob sie die Default-Pfade verwendet (wie GnuCash, QBankManager, KMyMoney) oder ob sie eigene Pfade verwendet hat, und sie weiss auch, ob sie zusaetzlich eigene Daten kopieren moechte. Zusaetzlich kann sie den Benutzer noch befragen, ob er einfach das ganze Verzeichnis kopieren will, und es kann den - eventuell langwierigen - Kopiervorgang in einer GUI darstellen. Das alles gehoert nun mal nach meiner Ansicht nicht in die Bibliothek, und deswegen moechte ich das nicht einfuehren. [...] > > 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 [...] Das zu aendern ist tatsaechlich einiges an Arbeit, denn dann muessten alle Stellen, an denen der Pfad z.B. fuer die Daten von Plugins zu Beginn zusammengestellt wird, entfernt werden, und stattdessen dieser Pfad jeweils vor Zugriff neu zusammengesetzt werden. Das bedeutet unnoetige Arbeiten am Kern einer derzeit unproblematischen Bibliothek, und das halte ich fuer den avisierten Zweck fuer nicht in Ordnung. [...] > 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. [...] Das wuerde immer noch nicht das Eingangsproblem loesen: Alles, was nicht direkt von AqBanking bei AB_Banking_Save() geschrieben wuerde, bliebe unkopiert und stuende somit nach einem neuen Start nicht zur Verfuegung. Schlimmer noch: Fuer die naechste startende Anwendung sieht es einfach nur noch so aus, als waeren diese Daten nie da gewesen. Daher noch einmal mein Vorschlag: Den Einbau einer Kopierfunktion in die Anwendung (ist ohnehin besser zu machen als im Packaging, weil dann klar ist, wessen Daten kopiert werden muessen). Diese Funktion sollte am besten das ganze Verzeichnis $HOME/.banking zu $HOME/.aqbanking kopieren, dann haetten auch andere AqBanking3-Anwendung keine Probleme. [...] > > 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? [...] Natuerlich, aber das sind ja nicht alle Daten, die sich in diesem Verzeichnis befinden. AqBanking liest und schreibt ja bei den Init-Funktionen nicht alle Dateien aus dem Verzeichnis. [...] > > 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... [...] Also das fuehrt doch jetzt zu nichts. Du solltest nicht auf dem "einmal" herumreiten, sondern die anderen Teile meiner Argumentation verfolgen. Der Einbau einer automatischen, selektiven Kopierfunktion in AqBanking ist ein unnoetig grosser Aufwand, der nach Deiner vorgeschlagenen Vorgehensweise Aenderungen am Kern von AqBanking und den Plugins erfordert. Dies nur zu dem einen (und einmaligen) Zweck durchzupeitschen, um der Anwendung oder dem Benutzer eine einmalige Kopieraktion zu ersparen, halte ich fuer nicht vertretbar. [...] > 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. [...] Also ich finde nun wirklich nicht, dass ich mich bei der Entwicklung von AqBanking zuruecklehne. Und ich verweise auch nicht nur die Benutzer auf die Konsole, sondern ich schlage vor, dass die Anwendung eine Kopierfunktion hat oder eben der Benutzer einen schlichten Kopierbefehl ausfuehrt. Ich sehe nicht ein, warum ich in den Gedaermen des derzeit recht gut funktionierenden AqBanking3 herumwuehlen muss, wenn die Sache auch anders so leicht zu beheben ist. Gruss Martin -- "Things are only impossible until they're not" Martin Preuss - http://www.aquamaniac.de/ AqBanking - http://www.aqbanking.de/ LibChipcard - http://www.libchipcard.de/ ------------------------------------------------------------------------- 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
