OFXDirectConnect works

Thu May 18 08:22:41 EDT 2006

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-----