Hendrik Boom hendrik at
Fri Nov 11 15:40:16 EST 2011

A few years ago I wanted some printouts of gnucash data formatted in a 
form that my wife and I could use.  It was frustrating to me that the 
easiest way to accomplish that was to reverse-engineer the gnucash file 
and hand-coding a C++ program that read in the XML file and further 
processed it.  The initial, usable, form of this program was written in C+
+ in about a day.  Over the years, I've embellished it in various ways, 
sometimes to change functionality, sometimes to accomodate subtle changes 
in the gnucash file format.

But it seems silly to duplicate stuff that's probably in gnucash itself, 
and is even maintained by the gnucash implementers.  And it's obvious 
that with the shift to a database, I should consider reading the database 
instead of the (probably derivative and deprecated) XML file.

I had looked at the gnucash source code, but I found it much harder to 
understand than the XML file itself.  I had asked for information about 
an API for understanding the internal gnucash state and was referred to 
some (IIRC machine-generated) documentation.  It didn't help much 
either.  In particular, it didn't make it clear what I had to do to set 
up the internal gnucash state that it was reporting on.  While a fine API 
for code that ws embedded within gnucash, it didn't really suffice for  
external code.

And looking at the guile interface for reports didn't help much  either, 
even though I was an experienced Lisp/Scheme programmer.  At the time (is 
this still the case?) the only usable documentation to the reporting 
subsystem was the source code for the reports themselves.  This 
definitely wasn't enough.  The report code was full of functions with 
obscure names and equally obscure significance.

  This isn't a problem with Scheme being a difficult language to learn.  
It isn't difficult.  It can be learned by a competent programmer in a day 
or two.  It's a problem with obscurity of the API the reporting subsystem 
provides to the Scheme programmer.

In subsequent years I've wanted to produce report output in forms other 
than HTML, which, as far as I know, is the only one supported by gnucash.

I've also wanted to write some custom data-entry software for getting 
data into gnucash.

Now presumably, given enough time, I'd have been able to overcome these 
obstacles to interfacing with gnucash code the way it obviously wants to 
be used.  But, of course, at the moments I was faced with the need to 
produce, there wasn't enough time.


Now I'm not really interested in just complaining.  If you'll forgive a 
lurker, but long-time user, from speaking up, let me at least make a 
proposal.  Yes, I know it will probably be a lot of work, and who will be 
found to do it, etc.  What I'd like to hear is whether there are serious 
flaws here, and whether it's ever likely to gain the social support to 
make it worthwhile to try, etc.

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

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


It's worth noting here that some systems that can be used as scripting 
languages are capable of handling the C and C++ interfacing on their own, 
requiring no significant footprint in the gnucash library itself.  (I'm 
thinking specifically  about Gambit C here, which is an implementation of 
Scheme taht can compile to C.  No doubt there are others.)

Other languages that different users might want to use on top of gnucash? 
JavaScript, Python, Ruby and Erlang have been mentioned as languages that 
are in the Lisp camp as far as semantics goes.  Several of them are 
interpreted.  Google has recently put out a language that's designed for 
programs that partly run on a server and partly on a browser.  Accessing 
gnucash from a browser, even only read-only, could be useful.

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.

-- hendrik

More information about the gnucash-devel mailing list