UI independance

Matthew Vanecek mevanecek at yahoo.com
Wed Feb 12 18:59:15 CST 2003

On Wed, 2003-02-12 at 18:43, Fred Malabre wrote:
> 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.

I'd prefer to see a 3-tier architecture, but even so, the separation of
the interface from the engine would be what you're proposing.  We should
not tie the engine too closely to the data store--if you do that,
developing new back-ends becomes more difficult.

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

The completion of the Postgresql back-end will actually enable that in
the current life cycle.  It sounds like you are looking for the engine
to act as a server to which the client interfaces connect.  That may or
may not be a good idea, depending on how it was handled.  We certainly
don't want to take away from being a personal and SOHO financial

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

That's true, if the Gnucash engine could act as a daemon, accepting
connections on sockets.  That's pretty much a re-write of the engine
API, though, or at the very least the insertion of a layer between the
client and the engine.  I don't think that the Gnome2 port is going to
cause enough of a re-write to handle something like this--it would need
to be an extension/addition.

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

WRT the PDA, I'd rather see a conduit written that takes the data from
the PDA and stores it in Gnucash.  The PDA application is not real
important, IMHO.  A modified version of Expense would server quite well,
for that matter.

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

Certainly a good idea. It could take Gnucash in a whole different
direction.  I don't know how do-able it is, though, given current
manpower.  I think the priorities for now, going into Gnome2, is the
encapsulation of the GUI and engine.  The back-end is pretty
encapsulated already.

Matthew Vanecek
perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'
For 93 million miles, there is nothing between the sun and my shadow except me.
I'm always getting in the way of something...

More information about the gnucash-devel mailing list