How modular is GNUCash?

[Derek Atkins]

UGGH!  No.

If you're going to do anything at this level at least use Corba.
Gnome already supplies a Corba system..  But I think you're completely
under-estimating the amount of work this would require.  You're
basically talking about wrapping several THOUSAND api calls in rpc.
And again, the engine is small.

Just to be clear in some real numbers here..  The engine itself is
only 37 KLoC.  Compare this to the total size of GnuCash, which is
like 241 KLoC.  So it's only about 10% of the code.

I think you're trying to optimize before you realize the problem.
Perhaps I don't understand the problem you are trying to solve by
wrapping the thousands of APIs in some rpc-like thing...  For the
record I'll state again that 99% of your work is going to be
implementing the UI.....  If you decide to abstract out the engine,
you're both over-optimizing and adding more work (meaning it's now
99.99%, rather than just 99%).

-derek

Fred <fmalabre at yahoo.com> writes:

> 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
> 
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at lists.gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available