Re: API-Addition

> Hmm, that's where I'm lost: Why should LibOFX support other format ?
> I think what LibOFX is in general used for is to do exactly what the name
> 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.

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

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.

Had I know I would have considered proposing a merge, but now it would mean 
two name change, which would suck.
 
> As for the world-unique account id: What do you really need this for ? When
> calling LibOFX you already have an outside context (either the application
> directly or AqBanking in my case) which already knows in which country you
> are (e.g. AqBanking has an extra field for this).

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.  

> And besides, what can you really do with this unique id ? You can't enter
> it in a check, can you ? And for banks with no branch id (some countries
> don't have any) this field looks quite odd (multiple spaces within).

You can have the user identify to which real world account it corresponds.  If 
you have a better format to suggest and can be represented as a single 
string, I am listening.

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

> > As for the WHY the account id was combined initially (it wasn't always
> > that way), it's that different countries use these numbers VERY
> > differently. Only that concatenation of them is likely to result in a
> > number the user can actually identify in every country.  It's also the
> > only way to make sure they are unique.
>
> As I said before: Why ? The application already knows in which country it
> is (or where the file came from), I would like to use LibOFX to access the
> structures rather than having to do it myself...

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.

-- 
Benoit Grégoire, http://benoitg.coeus.ca/

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

iD8DBQBCZ7R6mZ6zzPlLuwMRAsx6AKCOHWRxKhnBi0JLHSvjod1viBq6BgCggKQ9
bl/VyyPhminLYOBs/P1eXfo=
=a6gN
-----END PGP SIGNATURE-----