Re: Proposal for API-Addition

Hi,

On Wednesday 20 April 2005 05:49, ace jones wrote:
> On Mon, 2005-04-18 at 19:27, Martin Preuss wrote:
[...]
> On KMM, we try to solve this by making it easier to compile and cutting
> down on dependencies ;-)
Nice try ;-)
This only works for you because you can influence KMyMoney.
However, most other projects which might want to use LibOFX can not be changed 
so easily, and that's the common case (at least if the library is good and is 
used by many other projects, like LibOFX obviously is).

So cutting down the dependencies isn't always an option.

[...]
> Martin, are there other major packages that use this approach?  I'll
> admit, it seems a bit unwieldy, but I would like to do some research to
> see how it works on other projects.  Particularly asking their
> developers and maybe their library clients how it works.  (And ideally
> I'm looking for a high-profile, high user-base project here.)
Please go ahead ;-)

I didn't do any research on that, and my approach is not the result of a 
scientific study I must admit. It's rather empiric ;-)

I use it at least in all projects of mine, and it works nicely so far (since 
more than a year in case of Gwen).
I was able to add fields to structures (as my projects evolved) in the past 
without breaking binary compatibility (so depending projects didn't need to 
be recompiled).

[...]
> In any case, this is starting to sound like hacking C to make it work
> like C++.  Which is why so many of us abandoned C to use C++ anyway :-)
C++ itself is in some places hacking to make it look like Java ;-)
But seriously, working object-oriented is even possible in C (without too much 
trouble, it is more work in C than in C+++, though). 

It wouldn't be too much work in LibOFX either, because for many fields in some 
structs we'd only need getters (not setters, because internally LibOFX can 
still access the structures directly, I wouldn't want to change that).

When I think about it: It is even easier to hide the real structure of a 
struct in C than it is in C++-classes, e.g. when comparing my work with 
OpenHBCI (C++) and AqHBCI (C). For C you simply don't have to export the 
definition of the struct: Just do a "typedef struct SOMETHING SOMETHING" and 
your through ;-)

When I first started programming I used C++ and I liked it. 
But later I switched all my libraries to C, because C is quite easy and direct  
(no implicit operator-methods, I hardly understood which operator I had to 
override for objects which might get copied later when C-objects are stored 
inside... grmph). So C++ was quite frustrating for me... 
OTOH C-libraries/programs are very much smaller in size (even with the same 
functionality of the target) than C++ versions (e.g. comparing the current 
size of Libchipcard2 against the size of its predecessor)

But that's just me, and I'm a dinosaur, anyway (I used to write quite big 
projects in Z80 assembler in the 90ies, so it's obvious that C suits me 
better than C++ ;-)

[...]
> transactions, which means I just made myself more work.  I haven't
> thought about API's for that at all.  Perhaps you could post your HCBI
> API's for sending transactions as a reference?
[...]
The important API is that of AqBanking, because this is the layer between 
applications and backends.

For AqHBCI (the HBCI-backend) it is easy, because this library is aware of 
AqBanking and uses its structures.

But that's out of the question for LibOFX for obvious reasons, so you are free 
to choose whatever API you like, I'll adapt my backend to it.

In src/libs/aqbanking/types/transaction.h you'll find what AqBanking knows 
about transactions in general, this is the struct which is used by AqBanking 
and applications. Which fields have to be set depends on the backend (which 
relies on LibOFX in this case).


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