How modular is GNUCash?
warlord at MIT.EDU
Mon Mar 17 19:39:06 CST 2003
Honestly, I don't know. I'm not sold on that architecture. I think
that the engine is by far the smallest piece of Gnucash, and probably
the most portable. The client side of the RPC Backend was a full
GnuCash implementation -- the RPC was just an extension of the Backend
API. So, leveraging that doesn't help you.
Adding xml-rpc is, IMHO, the wrong solution. Passing XML byte-string
objects within an RPC is fine, but that's not the same thing.
So, I would still start by writing a GnuCash UI in Qt/KDE; once that
UI is written we can later decide on a way to improve and separate the
interface between it and the engine (which is what it sounds like you
want to do). However, I just don't see the value of such a separation
because the engine is so small....
Fred <fmalabre at yahoo.com> writes:
> 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 will do that as a define my needs for the KDE front-end.
> Derek, I understand your point. However I believe the extra work required for
> a rpc back-end worse it for the future, I was also thinking of a console
> client, a Zaurus client, and maybe a web client. Wouldn't that be cool ?
> On Monday 17 March 2003 03:37 am, no ahora wrote:
> > And what about using something like xml-rpc?
> > I think xml is a good thing.
> > ---------------------------------
> > Yahoo! Messenger
> > Nueva versión: Super Webcam, voz, caritas animadas, y más
> > #161;Gratis!
> gnucash-devel mailing list
> gnucash-devel at lists.gnucash.org
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
More information about the gnucash-devel