Hi, auch wenn ich die technischen Hintergruende verstehe, halte ich die Aussage, dass ein normaler Anwender mit "cp -a .banking .aqbanking" nicht ueberfordert ist, definitv fuer eine Fehleinschaetzung. Erst mal muss er das ueberhaupt wissen, dass er das tun muss. Auch wenn es irgendwo dokumentiert ist, muss er von dieser Dokumentation wissen. Dann muss er verstehen, wie und wo er das eingibt. Wenn ich sehe, wieviel Leute schon genug damit zu tun haben, zu verstehen, wie sie ihre GnuCash-Datei wiederfinden und wie viele Anfragen zu diesem Thema auf den Listen ankommen, ist das meiner Meinung nach schon Beleg genug fuer meine Einschaetzung.
Ich habe definitiv mehr Kenntnisse als ein normaler Benutzer und ich habe auch lange gebraucht, bis mir klar geworden ist, dass es fuer eine vollstaendige Sicherung nicht reicht, das Verzeichnis mit meinen Gnucash-Dateien auf dem Server zu sichern, sondern auch noch .banking in meinem lokalen Homeverzeichnis. Und da habe ich auch nur rausbekommen, weil die Onlinekontodaten auf dem PC meiner Frau nicht sichtbar waren, wenn sie dieselbe GnuCash-Datei geoeffnet, fuer die ich die Konten eingerichtet hatte... Jetzt machen wir die Onlinefunktionen nur von meinem PC, damit es z.B. keine Probleme mit letzten Abrufdatum etc. gibt. Aber das nur nebenbei. Der geaenderte Speicherort wird jedenfalls meiner Einschaetzung nach wohl dazu fuehren, dass ein normaler Anwender in der Regel seine Konto neu anlegen wird, weil sie nach einem Update nicht mehr da sind, und er sich in den meisten Faellen nicht anders zu helfen wissen wird. Ob das nun sinnvolll und oder zumutbar ist, ist ein anderes Thema. Eine Idee: Wie waere es denn, wenn die neuen auf Aqbanking 3 basierenden GnuCash-Versionen einfach weiter .banking verwenden wuerden. Der Speicherort soll doch konfigurierbar sein und so waere ein nahtloser Uebergang sichergestellt. Gruss, Manfred On Fri, 20 Jun 2008 07:43:24 +0200 Martin Preuss <[EMAIL PROTECTED]> wrote: > Moin, > > On Donnerstag, 19. Juni 2008, Micha Lenk wrote: > [...] > > > Wie gesagt, ich finde immer noch nicht, dass so etwas in die > > > Bibliothek gehoert. Eine Anwendung koennte soetwas einbauen, aber > > > die Bibliothek sollte das nicht tun. [...] > > > > Okay, akzeptiert. 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. > > 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? > > Ich entscheide mich immer noch fuer die sicherere Alternative: Der > Benutzer moege schlicht diesen einen simplen Kopier-Befehl eingeben. > Damit ist niemand ueberfordert und ich muss mich nicht um alle > moeglichen Eventualitaeten kuemmern. Der Standard-Benutzer gibt > einfach den Kopierbefehl ein, und wer das anders geloest haben muss > (z.B. wegen Parallel-Benutzung von AqBanking2, oder weil er andere > Pfade verwendet oder aber nicht alles kopieren moechte etc), der kann > das immer noch machen. > > 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 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). > > [...] > > 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? Dazu muesste ich schon aufwaendige Dialoge > einbauen (wohlgemerkt: Alles noch innerhalb von AB_Banking_Init()). > Hinzu kommt, dass AqBanking selber ja gar nichts von Logs weiss, denn > die speichert z.B. das HBCI-Backend. Dann muesste ich also noch > solche Dialoge fuer die einzelnen Backends schreiben, und das alles > nur, damit der Benutzer nicht "cp -a .banking .aqbanking" eingeben > muss? > > 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. > > > Gruss > Martin ------------------------------------------------------------------------- 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
