Re: API-Addition

On Thursday 21 April 2005 14:37, Martin Preuss wrote:
> > Last I looked, most of them only had a very minimal implementation of
> > QIF.
>
> Right, though this is quite a simple file format the details are quite...
> spicy ;-)

Indeed...

> > > What you're trying to do here is exactly what AqBanking is doing:
> > > AqBanking tries to abstract online banking and file import/export, so
> > > at least for me (and Gnucash, KMyMoney, QBankManager and later
> > > MoneyPenny) LibOFX doesn't need to support any other type than OFX/OFC.
> >
> > It sure was never marketed that way to GnuCash, and even if we have
> > Christian Stimmings on the Team, it the first I've heard about it.  In
> > fact all I've heard untill now (even if I did contribute build patches to
> > it) is "If you are not in Germany it of no use to you".
>
> That was true as long as OpenHBCI was used. However, AqBanking is a
> complete new project (and in conjunction with the HBCI backend) the
> successor of OpenHBCI.
>
> AqBanking is an abstract online banking layer (see my homepage in the
> footer below). Its concept has prooven to be working because currently
> AqBanking provides (via backends):
> - German HBCI
> - OFX Direct Connect
> - German DTAUS discs (paperless exchange with banks using floppy discs)
> - German value cards (GeldKarte)
>
> It also contains bank information modules (about 25,000 US banks, 20,000
> German banks and about 1,000 Austrian banks) and a generic import/export
> framework.

Ok, I'll try to look into it, if it works I'll consider merging.

> That's true, but my OFX importer (which is a plugin using LibOFX) works
> quite well so far. Of course I don't know how *all* fields are eventually
> used in every country, but I have quite an overview (because AqBanking aims
> towards the internation audience, not a single country), and the following
> fields are commonly used in identifying bank accounts around the world:
> - Bank code (sort code, routing number, Bankleitzahl)
> - sometimes branch id (not in some EU countries)
> - account id of some sort (mostly a number)
>
> The SWIFT documents also state that these are the values by which an
> account is to be identified (and these are BTW the values which are usede
> to construct the IBAN code).
>
> So having these fields in LibOFX is vital to my backend.

How many times do I have to repeat, I'm not trying to prevent your from 
getting at them, and you don't have to argue their importance, I've been 
working on these things for a few years now...
 
> Your constructed account id is not helping there, and as someone pointed
> out it isn't even unique.
>
> So why don't you want me to add these 3 fields to OFXAccountInfo ?

I explained that at length already.   I also explained where the would be 
available.

> > You can have the user identify to which real world account it
> > corresponds.
>
> See, this shouldn't be necessary, the program could do that automatically
> if it is handed the information which is available. I'd like to reduce user
> interaction to a minimum.

Now your are being europe-centric ;)  In North america (and I suspect in most 
parts of the world except for europe and some parts of Asia), 90% of the 
population do NOT have electronic facilities to enumerate their accounts.  
Even if they do, how do they associate "My savings account" with with the 
electronic version of it if the number doesn't contain the usual information 
that they are used to read on their check.

I've been there before, there used to just use the bank_id field untill it was 
pointed out that in many countries it is insufficient.

> > If you have a better format to suggest and can be represented as a single
> > string, I am listening.
>
> That's my point: I dont think this is necesary. However, for compatibility
> reasons I wouldn't want to drop this field, either, just want to add the
> threee fields...

Trust me, it wasn't always there, and it wouldn't have been put there if it 
wasn't necessary. 

> But the computer can't do this with your constructed id. With this id I can
> only match the account against those I already have from LibOFX, but in
> some cases the account already existed before invoking LibOFX (and has not
> the same id assigned like the one you construct). So in this case automatic
> matching is impossible.

Using BANK_ID instead certainly won't solve that in the general case.


> [...]
>
> > You make it sound as though I try to prevent your from doing so, I don't!
> > I just want you to do it with a separate low-level API.
>
> As I see it: Currently LibOFX *is* the lowlevel API, at least when it comes
> to your plans to make it a generic online banking/import layer (no insult
> intended: LibOFX is really good at handling OFX files, and I consider that
> real good lowlevel stuff).
>
> Abstracting all differences between multiple file formats should be a
> higher level, just above the currently available one in LibOFX (this is in
> my case done in AqBanking).

I started LibOFX and gave it countless hours to ensure that we'd do it ONCE 
for all OSS projects.  If another project took it from another end and got 
further at abstraction (and I'm satisfied of the abstraction is abstract 
enough), well it sucks for me, but i'd consider a merge.  Is there the 
Doxyged docs for Aqbanking somewhere on the web? 
-- 
Benoit Grégoire, http://benoitg.coeus.ca/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBCaA4gmZ6zzPlLuwMRAkU2AJ9ScgWF46DvAiYtB8DgDeYh1NSTrwCfW/Xo
bAVTHTgVCVmJzFSZ+WwA+Po=
=RdBd
-----END PGP SIGNATURE-----