bobgus at rcn.com
Tue May 3 15:32:44 EDT 2016
Sounds like a progressive idea.
A very similar approach which would be easier and more ‘main stream’ is to use a browser as the GUI. There are a number of frameworks which can be used to write the server such as RubyOnRails, Django, etc. These frameworks use MySql, Postgresql, SQLite in a database agnostic fashion.
> On May 3, 2016, at 09:16, 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
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
More information about the gnucash-devel