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
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
