I am not a developer but I recall seeing on one of the maillists very
recently that the infrastructure changes required to get to a true database
file structure should be completed sometime in 2018 (unless more volunteers
step up to help). Then ideas like yours might be possible.
David C
Sent from my LG G Pad 7.0 LTE, an AT&T 4G LTE tablet
------ Original message------From: Bob GustafsonDate: Tue, May 3, 2016 2:36
PMTo: Don Ireland;Cc: gnuCash Developer List;Subject:Re: Server/Client?
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.Bob G> On May 3, 2016, at 09:16, Don Ireland 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>
[email protected]>
https://lists.gnucash.org/mailman/listinfo/gnucash-devel_______________________________________________gnucash-devel
mailing
[email protected]https://lists.gnucash.org/mailman/listinfo/gnucash-devel
_______________________________________________
gnucash-devel mailing list
[email protected]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
