Re: API-Addition

On Wed, Apr 20, 2005 at 10:41:04AM -0400, 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.

Hi, Benoit.  Well, as the maintainer, it's undoubtedly your purview to
set the direction for the project.  I guess I don't consider it likely
for Martin or I to be able to change your mind on this issue...  But at
least let me try :-)

Moving libofx to other formats seems counter-helpful to me.  Great
low-level libraries do one thing and do it really well.  People know
they can count on it to do that one thing.  So when people thing, "Gee I
need a way to handle OFX files," they know they can turn to libofx and
it should solve their problem. 

Continuing to be "the solution for OFX files" allows the project to keep
a tight focus, and that way people who use it know exactly what it's for
and exactly how it should fit within their projects.

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

See, I haven't considered direct connect any different from the existing
use of libOFX, at least for interpreting OFX files.  The way I see it,
direct connect is just a way to prompt the server to send you an OFX
file.  The OFX file the server gives you is *the same as* the file you
would get by downloading it from your bank.

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

Incidentally, they are still not unique as-written. We would also need account 
type in there to make them truly unique.  Two accounts can have the same
number if they are different types.

</Ace>



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