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