XML-RPC interface

[Linas Vepstas]

On Wed, Sep 26, 2001 at 04:54:49PM +1200, Rob Brown-Bayliss was heard to remark:
> On Wed, 2001-09-26 at 15:00, Linas Vepstas wrote:
> 
> > What I keep trying to say is that most people should *not* look at the
> > backends at all.  Its clear that we still need to implement one or two
> > more, so that we can really have a generic server.   But ordinary
> > 'users' should be coding to the engine api.  The backends are supposed
> > to be off-limits, and have a kind-of special relationship with the
> > engine.
> 
> Having an xml-rpc server (or I guess in this case it's a xml-rpc client
> in place of a gui client) sitting on a machine, talking directly to the
> engine would allow incorporating gnucash into other apps...  for example
> (close to my heart) a POS system could use gnucash as the accounting
> system, leaving it free to deal with sales and stock management.

Maybe the gncuash engine is misnamed. The 'engine' is not a server, its
a client.  It was designed to be a client, not a server.  The 'backend'
was designed to be the server.  

> The site would then stil be able to choose either a postgres or file
> based back end.  The advantage as I see it of an xml-rpc connection is
> every language would then magiacally work with gnucash, rather than
> messing about wraping the current engine calls every time they change.

But that's wrong.  If you did that, then every time the engine API 
changed, you would have incompatible changes to the RPC protocol.  
You'd have the major problem of having to match client version to 
server version.  Imagine 100 POS terminals.  Suppose you wanted to 
upgrade the server, but could only upgrade 10 POS terminals a day.  
What would you do about the version mismatch? It would be a massive 
upgrade headache.

By contrast, the 'backend' is meant to deal with this versioning
problem.  Say, for example, the network protocol needed to be changed.
Then you'd use 'network-backend-version-1' for contacting old
servers, 'network-backend-version-2' for contacting new servers.

And the flip-side is also true: if the engine API changes, the backends
don't have to: the network format does not need to change just because
the engine API changed.   

For some small deployments, you can blow off the versioning problem.
But as soon as you have more than a dozen clients, the versioning
problem will be huge and will bite you in the ass.

-----------
I also think you over-estimate how hard it is to get language bindings.
SWIG automatically generates language bindings for a number of
open-source languages.  Its totally automatic.  It's like saying 'make'.
And for closed-source ones like Java, there are tools as well. 


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