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

[Linas Vepstas]

On Mon, Sep 24, 2001 at 10:08:10PM -0500, Bill Gribble was heard to remark:
> The situation now is you first make a "new session" call to the cgi
> script, which launches a stripped-down Gnucash that in turn opens a unix
> domain socket to do the XML-RPC io through.  The name of the socket gets
> passed back to the calling Java program, which uses it as a key for all
> future calls to get to the right instance of Gnucash on the server side.

In the good old days, the thing that is now called 'book' used to be
called 'session', because it was originally meant to be a session.
Someone changed the name on me; maybe its time to change it back.

Think about using a guid rather than a socket name to identify a
session.   The sql backend currently uses guids to identify sessions;
this concept should be (should have been) elevated higher up into the
engine api's.  

> Obviously this test doesn't use the engine at all, but it's easy
> to use the engine module and publish some subset of its symbols. It's
> sort of limited right now; there's no real support for any pointer types
> passing back and forth, etc.  For our app I have hacked up a very
> "special" (i.e. lobotomized) API that gets published to XML-RPC. 

Hmm.

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.

That's why the backend interface is 'deeper': you only need to make
one rpc call, that for 'commit-transaction', which will send *all* of
the data in one big block.

The engine was always meant to be a 'thin' interface on top of the
backend; the thin interface was supposed to mostly just 'marshall
together' (to misuse the word 'marshall') the data into blocks,
and to cache it so that setters/getters wouldn't be cross-network 
calls.  The backend was supposed to do the heavy lifting. 

Unfortunately, the engine kinda got fat & crufty.  Maybe now that 
the xml file-io code has been moded to its own subdir, the engine is 
getting thin again? 

Let me reiterate: the 'backend' is supposed to be the 'right' interface
for putting rpc code.  If it's not right, then I can only hope that its
close enough to be fixable.

> So the only thing the web server is doing is handling the SSL parts of
> the HTTPS transactions to send the data to and from the gnucash server.

Yeah, that's the beauty of it.  People under-estimate how much stuff
http automates for you, that you'd have to otherwise reinvent on your
own.  Also, with apache, I think one could use it to manage logins,
permissions, host-ip filtering, authentication, etc. 

People think that apache serves html, but its really more versatile: it
can serve XML, and that's a good thing.   

-- linas

ps. I think the correct cross-post is to gnucash-devel, not
gnucash-user.



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