Derek Atkins warlord at MIT.EDU
Sat Nov 12 12:55:08 EST 2011


Hendrik Boom <hendrik at> writes:

> (1) The bulk of the code for gnucash should be a shared library, whose API
> (s) provide all the essential functionality of gnucash.  This would 
> include code for starting up gnucash, shutting it down, reading gnucash 
> fies, opeining the usual gnucash window, and so forth.  The current work 
> of converting ad-hoc code to use Gobjects could go a long way to making 
> this API consistent. 
> (2) The gnucash main program itself should operate entirely by using this 
> library's API.
> Maybe (1) and (2) is how gnucash is already structured; I don't know.

This is already the case..  However it's not a single Shared Library.
It's a ton of shared libraries.

> (3) This library would be the basis for scripting interfaces to gnucash.  
> The API would make the gnucash library itself indifferent to the 
> scripting language being used.  Of course, the API must still be clearly 
> documented, or it will be practically useless.  Documentation in the 
> header files may suffice.

This is also the case.  The Scheme and Python bindings are based on the
C APIs by wrapping using SWIG.


> But now I'm getting far in advance of myself.  I'm currently arguing only 
> for a clear, conprehensive, documented API that others could use to build 
> their own edifices on top of gnucash.  That would open the gates to all 
> kinds of unexpected collaborations.

I agree wholeheartedly.  Are you willing to help document the APIs that

> -- hendrik

       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL:    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available

More information about the gnucash-devel mailing list