UI independance

Fred Malabre fmalabre at yahoo.com
Wed Feb 12 18:43:47 CST 2003


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.

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

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.

What do you think about this?

Fred.

PS: See this post on http://fmalabre.homelinux.net/gnucash/



More information about the gnucash-devel mailing list