Having experienced all of the benefits...

Geert Janssens geert.gnucash at kobaltwit.be
Mon Sep 15 09:26:32 EDT 2014


On Monday 15 September 2014 14:02:04 Colin Law wrote:
> On 15 September 2014 13:09, Geert Janssens <geert.gnucash at kobaltwit.be> wrote:
> > On Monday 15 September 2014 04:51:49 Steve wrote:
> >> Obviously (?) the fact that there does not exist a full fledge
> >> working version of GnuCash on mobile, and clearly (?) that is the
> >> direction where "we" are headed.  Having an app that simply
> >> records charges and provides an export/import facility, is not it.
> > 
> > Thanks, that's clear now.
> > 
> > And I'm eager myself to see a port of gnucash to mobile/tablet. It's
> > undeniably a form factor that complements traditional computers and
> > laptops and always within reach.
> > 
> > The code base as it is currently however is not portable to android
> > at all so it's no use trying to port what we have now to that
> > platform.
> 
> There is no need to contemplate a port of the s/w.  I believe the
> principle requirement is for a json http interface to allow
> interrogation and updates to the database.  Then the mobile app can be
> built on that, starting with basic features such as transaction entry
> and account summary display.  In the short term there would need to
> be a lock to prevent remote access while gnucash itself was running
> as currently it would not cope with the database being updated under
> its feet.
> 
> Colin

Hi Colin,

That's indeed one way to go and close to what I think a gnucash app should do.

It shifts the focus to next, closely related issue: GnuCash was not designed as a database 
application. I consciously left out such detail in my original reply, however since you brought it 
up... :)

I am sure I'm repeating what has been said in the past. GnuCash can currently use a database 
as an immediate write-back store.

This feature was written with reducing the risk of data loss in mind. Data loss that could occur 
with the xml file if you didn't save regularly enough and the system would crash. Using a 
database in current comes with a small additional side benefit that you gain some time when 
closing gnucash. You don't need to save anymore.

That's unfortunately all the current database implementation provides as "features". You can't 
access the database simultaneously because the master data is still kept in memory, not in the 
database. Also any change behind gnucash' own interface will not be seen by gnucash and 
potentially overwritten by an action inside gnucash.

Going further still: the database does keep referential integrity, but not all business restrictions 
are encoded in the database structure. I even think they can't be. So updating the database 
outside of gnucash comes with the real risk of invalidating your financial data. Things like 
transactions that no longer balance, splits that don't belong to any transaction, invoices and 
payments that no longer match, things like that.

And yes, you can argue all these restrictions can be implemented in your json api. Totally 
agreed, you can. But then you are effectively rewriting the gnucash engine as a separate 
project, because that is what the gnucash business engine was written to do. It will take a 
considerate amount of time and you will end up with two codebases to maintain, fix bugs in 
and implement new features in. That is not a wise thing to do in my humble opinion.

All of the requests about multi-user database access, web interface, mobile versions and such 
have been heard by the developers. It's these requests that have pushed the rewrite of the 
gnucash core that is currently ongoing. Such rewrite takes time. Available time is limited. So 
things go slow unfortunately. But the focus to enable these things is there.

Regards,

Geert


More information about the gnucash-user mailing list