Re: API-Addition

Hi,

On Thursday 21 April 2005 22:33, Benoit Grégoire wrote:
> On Thursday 21 April 2005 14:37, Martin Preuss wrote:
[...]
> > 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.
It works for nearly a year know, GnuCash uses AqBanking since 1.8.10, 
KMyMoney-CVS uses it and QBankManager is plain based on it. 
Trust me: It works ;-)

[...]
> > 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...
But as I understand it you want to create another layer first, which might 
take some time, and which is - at least IMHO - not needed at this point.

[...]
> > > 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
Generally I am ;-) but not in this case: Even North America uses routing 
numbers to uniquely identify a bank (at least the US do), and banks 
internally use account ids (be it either numbers or any other type of 
string). And these numbers/codes are used by the OFX servers.

[...]
> 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
No, but the bank has. And this argument better serves me than it does you: If 
I couldn't extract the bank id and account id (and yes, I know that you don't 
want to prevent me from getting them), then the user must enter them himself 
(because either way these ids are needed for communication with the banks OFX 
server). And if he isn't used to refer to his accounts by id it could pose 
quite a problem on him...

[...]
> 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.
That isn't much of a problem I think, because normally the user doesn't have 
accounts at every possible bank, and it is quite unlikely that one user has 
two accounts at two credit institutes which have the same bank id and account 
number.
The context the library is working in is not the whole world, it is just the 
user.

[...]
> 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
That was exactly the reason for me to write AqBanking, to provide a library 
which can be used by multiple other projects, so that they don't have to 
bother with file formats or banking protocols etc. 
Only a few people need to write the importers (and for AqBanking there already 
are importers for files in CSV, OFX, SWIFT, DTAUS and OpenHBCI1 format).
I just started working on a QIF importer, but the date formats etc kept me too 
busy for now ;-) I will continue that work later (or of course invite 
everyone to participate ;-)

[...]
> enough), well it sucks for me, but i'd consider a merge.  Is there the
> Doxyged docs for Aqbanking somewhere on the web?
I just put it online (http://www.aquamaniac.de/aqbanking/). The definitions 
for importer plugins is in 
(http://www.aquamaniac.de/aqbanking/apidoc/group__AB__IMEXPORTER.html)

The API doc is neither complete nor beautiful, but it serves as a starting 
point. Some of the source documentation is automatically generated and even 
ugly ;-)


regards
Martin

-- 
"Things are only impossible until they're not"

LibChipcard - http://www.libchipcard.de/
AqBanking - http://www.aquamaniac.de/aqbanking/
OpenHBCI - http://www.openhbci.de/


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click