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

[Jeb Bateman]

On Tue, Sep 25, 2001 at 02:02:58PM -0500, Linas Vepstas wrote:
> The traditional gnucash 'theory' is that the 'correct' programming
> interface/API is the 'engine' programming interface.  Part of this
> theory is that there are supposed to be 'engine backends' that know how
> to communicate with persistent-storage backends.

And from a client-side programming perspective, you shouldn't have to
worry about which data-store is being used by the backend, right?

> There are currently four backends:
> -- the file format backend, can save/restore from file.  This is a 
>    single-user, local-storage backend.
> -- the sql backend, can connect to local or remote database, supports
>    multiple simultaneous users.  Beta.  Works for me; might have
>    scalability or performance problems.
> -- the 'rpc' backend.  Uses rpc to talk to remote gnucash server.
>    Code exists, but its broken, not currently operational.
> -- the 'http' backend.  Uses http to manage connections.  Uses a
>    an enhanced version of the XML file format as the actual data
>    protocol.  Currently broken by recent file format changes, but it
>    used to kinda-work.  (The idea was that http would provide SSL,
>    authentication, socket management, state management, permissions,
>    etc ... all that communnications-level stuff that apache provides).

It sounds like the last two could be combined into an XML-RPC backend,
since it inherently runs over HTTP.  (Perhaps simplifying this will
lead to something that works reliably, instead of something broken.)

> Right.  You could put an XML-RPC interface in front of the engine.
> But I think it would suffer serious performance problems.  It would be 
> nasty to make an rpc call to set the payee, a second one to set the
> date, a third one to set the amount... etc. 

You don't have to make an rpc call for each piece of data.  The client
program collects data from the user, and then submits it all at once
to the XML-RPC server for processing...

> In designing the backend, the goal was to put the communications there
> (such as XML-RPC), so that we ship only entire transactions (or even
> entire lists of them) to the server.  One RPC call per block of 
> data.  Much more efficient.

Right.  I'm pretty sure you can do that ;-)

> Note also that one of the things that the 'engine' provides
> is a 'local cache' of the account data.  

You mean there is an "engine" for the client side too?  What language
is it written in?  Is it easy for any language to use this local data
cache?  I was thinking that each client could easily implement it's
own local caching if it makes sense, by querying or storing the data
it wants to cache via XML-RPC.

> Note that the 'cache' is not a theory: it actually works with the sql
> backend. As far as I know, there are are no bugs or problems with 
> the cache getting out of sync.

Cool.  If it's written and working, that's great; but I suspect it's
limited to a single language implementation, which is okay.  (People
writing sophisticated clients might want to choose that language to
save the work of implementing a cache themselves...)

> Since we already have an RPC backend, I presume that converting it to
> XML-RPC shouldn't be hard.   However, as I said, its currently broken
> and functionally incomplete ...

Right, so converting it might be a good excuse to fix it ;-)

> I'm totally confused about what Bill actually did.  I read the note
> several times, but couldn't make out where he put the interface, or 
> what got connected to what.  Bill is smart, but prefers to reinvent
> things on his own, rather than learn from the mistakes and experiences
> of others ... 

Hmmm.  It kind of sounds like someone was trying to re-invent the
wheel earlier by creating a custom RPC format.  Maybe it was less work
for Bill to add an XML-RPC interface instead of writing a new Java
library to communicate with the existing broken RPC backends(?)

> :-(  One problem with Java is that its just plain ugly. 

Shows how much I know about Java!  (I never use it :)

> Well, Those arguments were correct.  What I find curious was that those
> arguments were similar to the ones that resulted in CORBA being
> created in 1990/1991.  corba was supposed to fix the shortcomings of
> RPC. Unfortunately, corba was/is hard to use.   

Right I remember that argument also.  "Just use CORBA."  But it turned
out that something really simple that gets most jobs done took off...

> I was hopping that you were going to tell me that you had some
> explicit plans ....

No time at the moment, but I might start taking a look at the backend
code and interfaces sometime later, especially after Bill has checked
in his initial XML-RPC implementation...

Thanks,
-jeb