Fred Malabre <fmalabre at yahoo.com> writes:
> I was thinking about an evolution of Gnucash architecture.
>
> Today the architecture uses Guile to plug all kinds of components together
> (Engine, UI, ...).
> One of these modules may persist the data on different supports (XML file,
> external database, ...).
>
> The architecture I propose is to evolve to a client/server Gnucash.
> The server would be the engine and the persistence of data.
> The client would be the user interface.
> The server and the client could communicate using a socket connection with a
> Gnucash protocol.
There have been two prototypes for this. There is the RPC Backend,
and there was the GnuCash Network Backend. Both of these are attempts
at doing this.
> This architecture would open a lot of new possibilities for Gnucash:
> 1. Gnucash could become a multi-user engine, managing and synchronizing
> multiple clients. Eventually it could add multiple user rights to
> visualize/use only a set of accounts.
You can already do this today with the postgres backend. In addition,
the RPC Backend tried to do this, but wasn't completely successful at
allowing multiple clients access to the same data store. However
theoretically it could have been done.
> 2. Gnucash could be open to mutiple platforms through a client specific to
> each plaform. Then there could be a Windows client, a console client, ...
Uhh, you can do that already.
> 3. In the Gnucash roadmap, there were discussions about porting Gnucash to
> PDA. With this new architecture, it would just be a light client
> synchronizing with the server when a connection is established.
I'm not so sure that this.. PDAs tend to require their own conduits,
and honestly those can run now.
> I'm sure it could open a lot more possibilities...
>
> I also believe now is the best time to introduce this architecture for the
> following reasons:
> 1. Gnucash will have to be ported to Gnome2, which may well end up writing an
> all new client. Also, I started to work on a KDE UI for Gnucash. It would
> then become a new client as well.
No, I suspect that 85-90% of the code will/can be re-used in the
gnome-2 port. The only code that I know will have to be re-written is
the Guppi code and the HTTP code. We're not actually using the http
code for anything, so that can probably just be ripped out, leaving
Guppi. We'll also have to re-write the GtkCList code to use GtkCTree,
and we'll have the chance to replace the MDI code with a better
solution.
However I think you are over-estimating the amount of work in a gnome2
port.
> 2. It's not a big change in the Gnucash architecture. Today Guile
> inter-connect multiple components together, one of those is a Gnome UI. This
> Gnome UI would then be replaced by a server socket layer.
Note that turning gnucash into a client-server model has nothing to do
with its modularity. The RPC Backend was in gnucash-1.6, and
gnucash-1.6 wasn't modularized. So the fact that the code IS modular
is a red herring. It certainly helps in that you can write guile
scripts that only load SOME of the modules, but you are still looking
at it from the wrong direction.
Another thing to consider: Linas and I had discussed (on this list,
IIRC), the possibility of making a Bonobo Server out of Gnucash. This
would allow other (gnome) applications to talk to GnuCash and perform
functions. Similarly, it would be nice if GnuCash would act like
Netscape, Mozilla, Acroread, or lots of other applications -- detect
if one copy is running and "pass" information across.. This would
make it easier to turn GnuCash into a web plug-in -- the web browser
could just call "gnucash", and it would either start a new one or, if
one was running, pass the information into the running gnucash.
> 3. It wouldn't change anything for a casual end user, the server and the
> client would reside on the same machine and would be started and stopped at
> the same time, it will then be the same as it is today for such users.
I do object to the concept of the normal case involving two processes.
If I run "gnucash" as a user, I want it to be a standalone
application. When I quit it, I want it to die.
> 4. It is probably a good time to start working on a real-time transaction
> exchange protocol. More people will be interested with such a tool, as the
> banking industry may provide similar tools in a near future.
Exchanging transactions between whom?
> Creating a good protocol is the key. An XML based protocol seems to be a good
> option to allow evolution of the server without impacting the clients.
I would say some combination of XML and perhaps RPC would work.. Use
XML for the data representation, but RPC for the transport and
function call. OTOH, perhaps we could use CORBA, or maybe even some
scheme transport...
> What do you think about this?
I think it's a decent idea, but having gone down this road once myself
I would say it's a LOT bigger problem than you suspect.
As I said, take a look at the RPC backend -- I do think it's MUCH of
what you want.. But it's certainly not everything you want.
Also, you will find that going down this road will not help you with a
KDE front end... If you think it would, you're unfortunately deluding
yourself, or you don't understand the problem.
Good Luck,
> Fred.
>
> PS: See this post on http://fmalabre.homelinux.net/gnucash/
-derek
--
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