XML-RPC interface (was: Will GnuCash ever work for me?)

[Bill Gribble]

On Tue, 2001-09-25 at 14:45, Linas Vepstas wrote:
> I can't quite tell where you are slicing this cake.   Clearly,
> publishing things like 'xaccTransSetMemo()' would be rather inefficient,
> since you'd have to make dozens of rpc calls to build one transaction.

I understand your points, but they aren't relevant for this particular
application, which was the only reason I wrote the code.  I wasn't
planning on ever putting it in CVS until it started to look like it
might be useful for other people. 

We have a front end that's written in Java, and it's big and complicated
and has its own history and rationales.  This XML-RPC code is strictly
for the purpose of forwarding transactions entered by human hands (i.e.
at a rate of a few per minute) to a Gnucash engine from the Java GUI
that created them. 

A design decision I made (which shows in the sample code I sent earlier)
was that everybody who wants to use XML-RPC in gnucash needs to figure
out what API they want to publish for their app [1].  In our case, we
have a special API that allows a whole transaction to be sent in one
XML-RPC transaction.  The handler side of the API, which is Scheme code,
massages the Java transaction (which isn't structurally identical to a
Gnucash transaction, but isn't too hard to map onto one), figures out
how to make a Gnucash transaction out of it, then uses the normal
Gnucash engine API to stuff it in. 

So rather than needing a new "backend", which the engine API can drive,
we need a new "frontend" which can drive the engine interactively from
another language and possibly but not necessarily another machine. In
case it's not clear, this is a non-GUI or GUI-optional server version of
gnucash. We could have done it by some Java equivalent of g-wrap but
XML-RPC is there and it's cheap and simple.  

It's necessary to have different sockets with different instances of
Gnucash for different "sessions" because there can only be one GNCBook
open at a time per Gnucash instance *but* in practice on our system
there may be multiple users on the system using different GNCBooks
through the same CGI server machine.  The socket name identifies a
Gnucash process ID more than it does a GNCBook structure. 

b.g.

[1] In general, if we want a "generic" XML-RPC server for Gnucash, it
won't be hard to write a little function that just publishes every
symbol in the Gnucash API to XML-RPC.