langauge bindings [WAS: Re: GnuCash CLI v0.0.1]

Neil Williams linux at
Thu Jul 14 17:49:02 EDT 2005

On Wednesday 13 July 2005 7:33 pm, Daniel Tudosie wrote:
> On Wed, 2005-07-13 at 13:55 -0400, Josh Sled wrote:
> > > Are Java bindings wanted ? I am willing to implement them but as I
> >
> > You're welcome to contribute whatever you like, especially if you're
> > willing to support it. :)  Frankly, though, I'd like to see a specific
> > use for the bindings before/alongside them; random bindings that aren't
> > being used isn't a win.
> I totally agree on this one; I just asked because Java was mentioned and
> I assumed that Neil has thought of some use for them;

Sorry, a little background might help. I started on the GnuCash code to 
automate the creation of my daily invoices, using data from my Palm PDA. That 
quickly showed that I'd need to also get into the pilot-link code and this is 
where I have come across language bindings - Java, Perl and Python. I didn't 
mention Python because I've never learnt it and haven't understood it even 
when I've read it! (A bit like my reaction to Scheme.)

So I mentioned language bindings - using Java only as an example - not because 
I had any GnuCash role in mind but because I had seen such bindings being 
used by others in pilot-link.

> but I am also 
> working in C/C++ and Scheme is not a just strange word ;-) - so I will
> contribute to the existing code/implementation (when I will have
> something to contribute with)

You'll be very welcome here.

> However, I realize that I was not so clear... I do not want to
> reimplement existing logic in another language but providing an
> interface would be nice... of course: if there is something meaningfull
> to use it for (e.g. a Java binding could be used for web interface either
> applets or servlets, JSP)

That would compliment the current work very well, IMHO.

> > It would be further better to move a lot of the logic, which is tightly
> > coupled to the UI, down into a layer just above the current "engine",
> > and expose it via an API.

A clearer dividing line between GnuCash and QOF is appearing (at least to me) 
as part of the CLI and I am cleaning up a few areas so that GnuCash can use 
QOF more like other QOF programs - with the aim of GnuCash using QOF as an 
external library sometime after G2 - removing all qof*.c|h from src/engine 
and src/backend/ and ancillary files.

The CLI itself may illlustrate the kind of logic required and how it could be 

On the CLI, I'm implementing a 'shell' mode based on a pilot-link example to 
ease data entry with add [entity], edit [entity], load [book], write [book], 
sql (possibly interactive) and merge [book] functionality. This will be done 
using nested menus, ala GnuPG - gpg --edit-key or gdb although actually based 
on code from pilot-link (dlpsh.c). I'll also investigate a possible 
'recording' idea that shell commands could be exported as SQL to be run again 
at a later date. I'm quite confident that the CLI can have at least Perl 
language bindings - Java and Python would need someone else's skill but 
there's no reason to think they wouldn't work. Shell mode should be ready for 
the first release, the rest will keep me occupied after G2.

> This would be great... I think it was discussed before and the
> conclusion was that is not that easy, it needs some serios thought and
> engineering to make a more better/robust/etc architecture...
> However, a time will come when this should be done

I agree and I don't think it's as hard as it may appear. It's non-trivial and 
must be carefully planned, but I don't think it's something we can afford to 
let lie.

G2 is clearly everyone's priority - (I'm only writing the CLI now because 
it'll help me finalise my new code in QOF and therefore G2). 


Neil Williams

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url :

More information about the gnucash-devel mailing list