On 05/03/2016 08:02 PM, John Ralls wrote:
On May 3, 2016, at 10:16 AM, Don Ireland <gnuc...@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
Yes, MVC is the way to go - and is the pattern used in Ruby on Rails for
example.
If the 'state' is stored only in the database (again, like Ruby on Rails
- the Model part of MVC), then concurrency is handled by the database.
Postgresql (for example) does an excellent job of handling concurrency -
no extra sweat by the application programmer.
To make the programming easier - there are IDEs available. I use
RubyMine for RoR applications.
Regards - Bob G
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
