gnucash at donireland.com
Tue May 3 21:16:05 EDT 2016
Thanks for the follow up.
"You seem to be a bit confused about task separations, though."
What I was suggesting is that the GUI would display the existing records and provide a way for the user to tell the server to create new records via API calls. Other than that, all processing would be done by the server. And from what you said, it sounds like that's where it's headed.
I'd offer to help with this effort but although I've done some programming, it's all been for Windows (I wouldn't even know where to begin programming for cross platform). That and I'm trying to get a new business off the ground - - which is why I sought out a good accounting software - - in addition to my full time job leaving me very little free time.
On May 3, 2016 8:02:53 PM CDT, John Ralls <jralls at ceridwen.us> wrote:
>> On May 3, 2016, at 10:16 AM, Don Ireland <gnucash at donireland.com>
>> 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
>> 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
>> · 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
>> · 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
>> 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.
More information about the gnucash-devel