How modular is GNUCash?

[Fred]

I have almost no knowledge of the internal of Gnucash, so I can be completly 
wrong.
I want to use the engine, I don't want to bypass it.
I believe I used a wrong vocabulary. Let me explain again...
What I wish I could do is to communicate with the engine using xml-rpc.
Thus, I would have a method i would call through xml-rpc and ask for the last 
30 transactions, and the call will return with the last 30 transactions.

Does it make sense ?
I think there is not much work, it's basicaly encapsulating the calls to the 
engine in xml-rpc methods...

I was thinking of a script starting an xml-rpc enable engine and then starting 
a KDE front-end to connect to it. Everything should shutdown itself, then it 
would be transparent for the client.

Fred.


On Monday 17 March 2003 06:10 pm, Linas Vepstas wrote:
> On Mon, Mar 17, 2003 at 05:54:24PM -0600, Fred was heard to remark:
> > This is what I'm looking at.
> > I read in the archive some discussions about the rpc back-end.
> > I also saw some code in src/experimental/cgi-bin (or something like
> > that).
> >
> > I will come up with a proposal of xml-rpc methods, client oriented (as
> > opposed to Gnucash engine oriented).
>
> I think you misunderstand what the engine is.  The engine is supposed
> to provide a common API for both a client and a hypothetical server.
>
> The whole point of the engine is to be able to say, in very simple
> terms,
>
> 'open this file and read it'
> or 'open this db and read it'
> or 'open this rpc server and read it'
>
> then
> 'get me all transactions since july'
> or 'give me the last 30 transactions'
>
> and then
>
> while (trans) {
>     date = xacctransactionGetDate (trans);
>     amt  = xaccTransactionGetAmount (trans);
>     txt  = xaccTransactionGetDescription (trans);
>     gui_display (date, txt, amt);
> }
>
> The idea behind the engine is that you only need to write the
> 'gui_display' routine; the engine does the rest.
>
>
> I will gaurentee you that if you don't use the engine, then you will
> reinvent it.   If you aren't aware that you are reinventing it, then you
> will reinvent it badly.
>
> If you want to reinvent the engine, that's OK, as long as you are aware
> that is what you are doing, and that you have a stated design goal (e.g
> make it slimmer/smaller/more memory efficient) and work to that.
>
> --linas