Re: API-Addition

On Wednesday 20 April 2005 16:41, Benoit Grégoire wrote:
> On Wednesday 20 April 2005 06:13, Martin Preuss wrote:
> > On Wednesday 20 April 2005 11:38, Martin Preuss wrote:
> > > Therefore I propose to add some fields to OfxAccountData which
> > > represent at least the account number (we could call it just that:
> > > "account_number"). We should also add a field "bank_id" and maybe
> > > "branch_id".
> >
> > And while we're at it: Maybe we should add a field for the brokerId, too.
> >
> > I see no reason why we shouldn't make all valuable information from the
> > OFX file available to applications...
> >
> > Other opinions ?
>
> I'd like to veto that.  As I said before, Libofx is moving AWAY from
> sending the OFX data as it is, I am trying to abstract and interpret as
> much as it can from it to shield the application from bad bank
> implementations and difficulties of interpretation (Investment transactions
> are especially problematic).  Not having structs with several dozens of
> elements each is a positive and important side effect.
>
> Libofx must be able to support formats OTHER than OFX, even if it has
> strong roots in OFX.  Like many project, LibOfx suffers from inertia.  The
> same structures are currently used for parsing data and for client
> communication. It shouldn't be that way.  OFX data should be parsed in OFX
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.
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.

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

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

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.

[...]
> Obviously DirectConnect will need access to more information than what is
> given by the normal API.  I am not convinced it needs access to the whole
> low_level structures, but it certainly need's it's own API, if only for
> account enumeration.
Well, I don't need access to the *whole* low_level structure, but at least to 
what's commonly used in banking applications: Bank id (routing number/sort 
code/Bankleitzahl), maybe branch id and of course account id.

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


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/


-------------------------------------------------------
This SF.Net email is sponsored by: New Crystal Reports XI.
Version 11 adds new functionality designed to reduce time involved in
creating, integrating, and deploying reporting solutions. Free runtime info,
new features, or free trial, at: http://www.businessobjects.com/devxi/728