Re: API-Addition

On Wednesday 20 April 2005 14:24, Ace Jones wrote:
> 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.

Considering how uneven support for different file formats is in the different 
OSS finance managers, id say there is a pressing need for a middle layer 
library.

I've never meant for libofx to be "low level", even for OFX.  If fact, the 
ONLY thing a low level OFX library would buy you is the SGML parsing and data 
structure reordering.  Otherwise, you'd be almost as well off parsing the OFX 
files directly.

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

The "focus" of libofx in my mind is to help projects reuse importer code.  Now 
that it'S finally happening, I certainly don't want to move away from that.  
I really don't mind if there is a LOW level API, one is needed interanlly 
anyway, may as well let clients use it if they are so inclined.  But from the 
begining the goal of libofx was to make OFX less COMPLEX.  As I extended 
support for investement transactions, I quickly found out that I put the 
abstraction at the wrong level.

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

Yes, that's what I understood.  I wish I had more time to explain more fully 
what I had in mind (or even write a design document), but I just can barely 
keep up with this thread as it is.

What I think is the clean way to do this is to declare you OfxAccountInfo 
structure annonymous and and add a to toString method that would give a 
concatenated account type + account_id.  The structure would also contain 
everything it currently does.  Everyone will be happy.

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

See, you just found ANOTHER regional diference.  In Canada two accounts of 
different types DO have different number, even if they are part of the same 
"account".
-- 
Benoit Grégoire, http://benoitg.coeus.ca/

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

iD8DBQBCZ7CPmZ6zzPlLuwMRArbgAJkBBdozTNmZmrglhlxwUn4w4dwlSwCgmtgb
gopRtqY4k19CAMnkQy4HfcQ=
=7M7T
-----END PGP SIGNATURE-----