Having experienced all of the benefits...

[Geert Janssens]

On Monday 15 September 2014 12:01:27 Derek Atkins wrote:
> Colin,
> 
> Colin Law <clanlaw at gmail.com> writes:
> > 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.
> 
> This has been repeated multiple times over the past couple years, but
> the more I think about it the more I think this isn't exactly the
> right answer.  For one thing, it requires a server, and most people
> don't have or cannot run a server.  For most people it would limit
> them to having a working app only on their home network, which sort
> of defeats the purpose of having an App on a device.
> 
> The alternative would require *someone* to run a server for people. 
> But I know that *I* wouldn't trust anyone else to do that (although I
> suppose there are plenty of people who would, otherwise mint.com
> wouldn't have a business).
> 
> However I don't think it behooves us to *require* such a service to
> exist in order to have an App.
> 
A very valid point, thank you.

In my opinion there should be room for both approaches. Some people will prefer a client-server 
solution, others a more standalone app.

The computing landscape has been changing a lot in recent years. And with that the way in 
which people interact with computing devices.

I really think it would be good for GnuCash' future to keep these new interaction ways in mind 
while making long-term design decisions like the current engine rewrite. (I think we do by the 
way).

For me the engine should become a powerful library that exposes all features gnucash has to 
offer with good scripting bindings. On top of that many scenarios could be built:
- the current plain desktop app
- an independent mobile app
- a webinterface with or without a mobile client
- integration in personalized workflows

Maybe not all of this *will* happen. I certainly won't have time to realize all of these possibilities. 
I just want to keep the barriers towards these possible alternatives as low as possible. So others 
can build on it.

On the bright side, our current engine is already fairly powerful and we do have guile and 
python bindings. So we are in a good position to push this flexibility even further. The 
bottlenecks to tackle are well-known:
- reduce engine dependency on scheme (an important portability blocker)
- drop glib dependency (another portability blocker)
- centralize *all* business logic in the engine (parts are currently in the GUI code)
- make gnucash a real database program (brings multi-user concurrent access and solves the 
http/json loading issue)

That's it. Not too much really, is it :)

Geert