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

[Linas Vepstas]

On Tue, Sep 25, 2001 at 03:23:58PM -0500, Bill Gribble was heard to remark:
> 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. 

OK, yes, that's indeed the 'intended' use of the engine api.

> So rather than needing a new "backend", which the engine API can drive,

Right. There aren't supposed to be a lot of backends; only a few. As I
said, the backend does the 'hard work', and that means its hard to write.

That said, it seems obvious that we really should someday finish making
the rpc and/or the http backends functional.  That way, you really can
get the 'caching' advantages that I like to talk about ... but of
course, until someone clamours for this, it won't happen ...

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

Yeah, OK.  According to the the Java folks, that would have been JNI
(I think its JNI, 'java native interface', to call into C libraries).
The cross-network stuff would be Java RMI (remote method invocation).
And Java RMI supports a native java-rmi protocol, and also the corba IIOP
protocol, and, I wouldn't be surprised to hear that someones done a 
Java RMI-on-top-of-XML-RPC  .... You could have done a 'pure' java
solution if you had wanted to be a java purist.  But that's a political,
not a technical decision ...

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

I don't quite understand. Clearly, the GUI can only operate one 'book'
at a time.  But the engine doesn't (shouldn't) have any globals, and
so it should be possible for one process (that is coding to the engine
API) to open multiple books at once.  I've never tried this ... 
I don't know if we're really clean on this.

There's the obvious unwritten rule that one must not try to split a
transaction between differnt books.  But there are utilties, e.g.
xaccGetBookFromTransaction() that, given a transaction, will tell you 
which 'book' its from.   

So I beleive you should have been able to write a single process that
routes different transactions to different books as they come in.

-----
The converse is also true, at least with the sql backend: you can have
multiple gnucash engines updating the same database at the same time.

This is why I say that the gnucash 'book' is misnamed.  It was designed
to be a session,  but the common 1-to-1 mapping lead to some confusion.


--linas


-- 
pub  1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <linas@linas.org>
     Key fingerprint = 8305 2521 6000 0B5E 8984  3F54 64A9 9A82 0104 5933