-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Reiser schrieb: > Thanks to the efforts of Martin Preuss and Christian Stimming, the > gwenhywfar/aqbanking/gnucash coordination works for connecting to > financial institutions using ofxdirectconnect.
Great! Thanks for the feedback. > Christian: what front/backends do I need to configure for aqbanking to > cover all the gnucash supported connection methods? I've been building > only for ofx, but if I'm going to take screen shots for help docs for > setting up aqbanking, I might as well get all the backends a gnucash > user might want to use included. For the record (and the other devs here) I'll shortly explain what the meaning of these "frontends/backends" is in aqbanking: "Aqbanking" at the core is an abstraction library for online financial transactions. It abstracts from concrete file formats (e.g. OFX, QIF, or MT940) or communication protocols (e. g. HBCI or HTTP/SSL). The core aqbanking library (libaqbanking.so) does not contain any of those, and any application that uses the aqbanking library does not need to know about the actual file formats or communication protocols as well. Instead, the implementation of any such concrete file formats or communication protocols are located in particular "backends". For the convenience of the user, the source code of all available "backends" is already included in the tarball of aqbanking. For compilation and installation, particular "backends" can be selected by the configure-option --with-backends="...". The application that uses aqbanking neither knows nor cares about the particular backends that are installed or being used. So, to answer the first part of Davids question: You should add as many "backends" in aqbanking as possible, because gnucash (which doesn't know about the actual backends installed or in use) will support all of them. The only practical restriction is that some backends introduce additional library dependencies. This concerns the "aqofxconnect" backend which requires "libofx" (but obviously you have that installed already), and the "aqgeldkarte" backend which requires "libchipcard". And due to some bank NDA the "aqyellownet" backend is shipped as a binary-only library, so it might be unusable on non-Linux platforms. Apart from these three, all other backends should be included always. As for the "frontends": The aqbanking library abstracts not only from file formats and communication protocols, which can be viewed as lower layers, but aqbanking also abstracts from the upper layers, namely from the implementation of user interactions. Every non-trivial online action will require some user interaction, e. g. password entry or status message printing. Aqbanking provides many abstract hooks for all of these interactions. An application that uses aqbanking can provide the implementation to all of these hooks by itself (which is what gnucash currently does). Alternatively, the aqbanking developers provide the implementation of required user interactions in so-called "frontends". The aqbanking tarball ships with "frontends" for the most common user interface environments: "cbanking" for command line, "qbanking" for qt3-based programs, "g2banking" for gtk2, "kbanking" for KDE which has some additional functions on top of "qbanking". For compilation and installation, particular "frontends" can be selected by the configure-option --with-frontends="...". To answer David's second part of the question: You should add as many frontends as possible. The only practical restriction is that some frontends introduce additional library dependencies. In this case you should at least have "cbanking qbanking". There's a last issue here: The configuration of any online banking access, especially the initial setup, is (or can be) an extremely complex task, and by definition it strongly depends on the particular "backend". The configuration GUI code therefore cannot easily be added to an application, because earlier I said the application doesn't know about the "backend" of aqbanking that is being used, so it cannot implement those backend-specific configuration dialogs. For that reason the aqbanking developers decided to add extra executables to each "backend" in aqbanking (called "wizards") that fulfil no other task than guiding the user through the (potentially complex) configuration setup. Since these by definition also need user interaction, they need the functionality provided by the "frontends" above. Wizards are provided for the command line environment (which need the "cbanking" frontend) and for qt3 environment (which need the "qbanking" frontend), but not (yet) for gtk2. For this reason the users of aqbanking in gnucash will need to compile that "qbanking" frontend in aqbanking as well, because otherwise they wouldn't be able to use a graphical setup wizard for their configuration setup. This doesn't introduce any library dependency on qt3, but gnucash users will need to call that wizard-executable which in turn has a qt3 dependency. Alternatively the configuration setup has to be done on the command line, but that's not what the majority will want to do. :-) Regards, Christian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRGxnEWXAi+BfhivFAQKFfQP/azDS4JFDPytQ9UN90WCAz46ggL3g1xnF /ZKJ0pQOo4OGIrxPZLHWjhiF74twqfAmXPYE8fhTnoKAc4K4W2EuwLJmoBA5thtC phUjRRxr/2v6ftEzNIYXtmuG/DnIKFCoY/bXExW/IWjppJzsY9SxkvQhJoKgVjB1 c7e1aRSlSgw= =U6Sv -----END PGP SIGNATURE----- _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
