Proposal for API-Addition

Hi,

while looking through the new code for direct connect I thought that it might 
be nice to have constructor functions at least for those structures which are 
created by applications.
These are at least OfxAccountInfo and OfxFiLogin.

The reason is simple: Without those constructor functions an application has 
no other choice but creating such objects by the following kind of 
instruction:

struct OfxAccountInfo ai;

So whenever we add a field to this structure in LibOFX all depending 
applications/libraries need to be recompiled (because the instruction above 
does not allocate space for additional fields).

When having a constructor function the application can still use the approach 
shown above, but in addition it can allocate objects this way:

struct OfxAccountInfo *ai;
ai=ofxaccountinfo_new();
...
ofxaccountinfo_free(ai);

So when a new field is added to OfxAccountInfo the application will still work 
as before. It will ignore all additional fields it doesn't know of, but it 
will work without recompiling.

Why am I proposing this ? 
As you know Libofx is used by such big application as GnuCash and KMyMoney. 
Recompiling these applications can take a very long time (and could be too 
much for inexperienced users). It would be nice to not have to do this only 
because a field has been added.

However, if we would like to do it perfectly, we would have to protect the 
members of all structures and classes by getter and setter functions, to 
introduce constructor and destructor functions for all structs/classes and to 
hide the real definitions of the structures.

If we did this, then adding fields or members would in no case require 
recompiling depending projects. But what's more important: Newer versions of 
LibOFX would get much faster into distributions, because already depending 
applications could still be used without any changes to their dependancies 
(and without recompiling, this means less work for the distributors and thus 
makes it more likely to get new versions into distris fast).

I did the same thing with my projects (most notably AqBanking, AqHBCI and 
Gwenhywfar), because e.g. GnuCash (currently my main depending application) 
has quite long release cycles (at least compared to AqBanking) and is not too 
easy to compile (at least for inexperienced users), so changing the API in a 
way that users have to recompile GnuCash was out of the question.

With this approach I was able to add new features to AqBanking or Gwenhywfar 
(which sometimes needed new fields in existing structures) without breaking 
binary compatibility (with Gwenhywfar about 10 times until now).

Well, this would be quite a radical change, so maybe you don't want to do it 
right away. However, before a next major release of LibOFX we might at least 
want to add the constructors, destructors, getters and setters, so that 
applications may switch over smoothly.

This would have two advantages:
1) existing applications could still be compiled
2) new applications can already use the new approach, which would make them 
ready for future versions of LibOFX

After some time the real structures used can be hidden so that applications 
are *required* to use the getter/setter functions. And that would be the 
moment when the goal described above has been accomplished ;-)

Why now ?
Because we are about to add completely new code (well, Ace is, to be exactly) 
which IMHO will require a new major release anyway, so why not start 
now ? ;-)


Any thoughts ? Flames ?


regards
Martin

PS: @Ace: I didn't think that the new code in LibOFX would make it *that* easy 
to write an OFX-DirectConnect backend ;-) Really nice work ;-)

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