Re: API-Addition

Hi,

On Thursday 21 April 2005 16:11, Benoit Grégoire wrote:
[...]
> > suggests: Handle OFX/OFC files. Why would you want to support QIF or
> > others ? Most applications already have their own implementation for
> > these other formats, so they don't need LibOFX to do that.
>
> 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 ;-)

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

[...]
> It's always been told clearly that Libofx wanted to be a financial layer
> eventually.  When I asked to re-use some of the HBCI work, I was told that
> none of it was general enough was general enough, and didn't pursue it
> further.
As I said, that was true with OpenHBCI which only was an implementation of 
HBCI (and could not be used for anything else).

[...]
> Are you claming that AqBanking knows which fields are used and how they are
> used in every single country in the world?  I presume not.  No one can.
> Heck, handling currencies properly is still a problem for most packages.
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.

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 ?

[...]
> 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.

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

>
> > It's just as simple as this: I'm using LibOFX to get as much information
> > from OFX/OFC files as possible. Having to parse basic information (which
> > comes in single, distinguishable elements) out from an artificially
> > combined item kinda defeats this purpose.
>
> Off course it does, it's meant to be read by human, and to be and
> unformatted string of bytes for a computer to be used for account matching.
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.

[...]
> 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).


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