Re: API-Addition

Benoit GrĂ©goire <[email protected]> Wed, 20 Apr 2005 10:41:04 -0400
Newsgroups gmane.comp.finance.libofx.devel
Organization Technologie Coeus
Message-ID <[email protected]>
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 specific 
structures (when there is a need), and then use setters to set the 
corresponding API structure.  Same with QIF, same vith CSV, IFX, etc.

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.

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.

I wish I had more time to actively help with this, but I'll be out of the 
country for most of the month of may. 
-- 
Benoit Grégoire, http://benoitg.coeus.ca/
signature.asc (application/pgp-signature, 189 B)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBCZmoCmZ6zzPlLuwMRArGSAJ9sD0BIspaQ4TH/ItXs/lOqCyR8pQCgguQj
Md1coo/pKDgkREAmUzbJcQ8=
=Bk/3
-----END PGP SIGNATURE-----