langauge bindings [WAS: Re: GnuCash CLI v0.0.1]
linux at codehelp.co.uk
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
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).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20050714/a09bcfaa/attachment.bin
More information about the gnucash-devel