Server/Client?

John Ralls jralls at ceridwen.us
Tue May 3 21:02:53 EDT 2016


> On May 3, 2016, at 10:16 AM, Don Ireland <gnucash at donireland.com> wrote:
> 
> I’ve been using gnuCash for the past 3-4 days and really like what I’ve seen so far.  I’ve read that the dev team is planning to rewrite the code.
> 
> Might I suggest breaking it into a server (with an API) and a client (providing the GUI)?  This would allow for the GUI to be used on any multitude of devices and device types.  This would also address the current need for users that are using a MySQL back-end to be experienced with MySQL.  My vision of this is to embed SQLite into the server code directly.  Then the server would maintain SQLite file for its data. 
> 
> ·         A client would communicate with it via API calls to create transactions, accounts & scheduled transactions. 
> ·         A client would communicate with it to get an updated list of these records as well.
> ·         If the client is unable to communicate with the server, then the client can not modify an existing record but would be able to create NEW records which would be stored locally in a queue.  When a connection to the server becomes available, the queue would be processed and new records would be added.
> ·         If the client is able to communicate with the server, then the client can “CHECK OUT” a record for editing (which COULD include delete).
> ·         Whenever the server receives any updates, it would push the changes out to all the other devices that are “Subscribed”.  This would use the Google Cloud Messaging system to push these notifications which the clients would automatically process.  The notification would tell the clients specifically which records that they need to download it order to get these updates. 
> ·         The server would handle creating any new transactions that are the result of Scheduled Transactions (to avoid having conflicts with the clients trying to create them. 
> 
> The server could be installed on the same pc as the GUI thus creating more of a "local install" if that's what is needed.  The server could be installed on a Raspberry Pi, an individual computer or a full fledged server. 
> 
> Having done this, anytime someone comes up with a new device (new smart phone OS for example), a developer would just need to create a gui client that communicates with the server.  Someone could even create a gui that works via PHP thus enabling a web view (similar to using php to create a web interface for an IMAP account).  This would also make it easier to develop EXTENSIONS (to tie in a custom CUSTOMER MANAGEMENT SYSTEM or similar).
> 
> One might say this is not very friendly for a user who isn't tech savvy but I would argue that for the most part someone who isn't tech savvy is probably buying commercial software (quicken).  If a non-savvy person IS using gnuCash, it was probably set up for them by someone who IS tech savvy. 
> Don Ireland
> _
 
There's a single-application pattern for separating the guts from the GUI called Model-View-Controller, or MVC for short. GnuCash is halfway there but there's a lot of controller code and even some model code that's found itself in the GUI code and needs to be cleaned back out. Volunteers needed to speed up that process.

You seem to be a bit confused about task separations, though. Either the processing happens on the server and only display events are sent and received by the GUI client (XWindows would be an extreme example) or the processing happens on the client and the server handles the database transactions (the planned design we're working towards, with a SQL backend). Having both ends able to do processing means that you have to control concurrency somewhere in the middle. That's harder and not really useful.

GnuCash already has infrastructure in place for extensions. It's used extensively in the program's internals, and is reflected in all of those "loading" messages that make start up so slow.

Regards,
John Ralls





More information about the gnucash-devel mailing list