Having experienced all of the benefits...

[Geert Janssens]

On Monday 15 September 2014 16:56:40 Colin Law wrote:
> On 15 September 2014 14:26, Geert Janssens <geert.gnucash at kobaltwit.be> wrote:
> I entirely agree that would not be the right way to go.  I had assumed
> that the json i/f would be an interface into the GC codebase, not
> into separate code.  So there would only be one set of code managing
> the database.
> 
For sure that would be the best place to add it. :)

> > 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.
> I was not saying that the current approach is not correct, just that
> to provide GC on mobile devices is not a port of existing GC code.
> There is work to do, on the mobile device and extensions to the GC
> code but it is not a port.
> 
Allow me to think out loud for a while.

A client server system works more or less like this:
The client part should be able to query the server side and send it update requests. The server 
side should respond to queries and perform updates only if the request adheres to all 
accounting restrictions. The client side should not be aware of these (in theory).

In our existing code base the server side is roughly our engine code. The client side is currently 
only implemented as a GUI, but a json interface would hook into it on the same level.

The code as it is now unfortunately doesn't follow the strict client server separation as 
described above. That is, part of the accounting restrictions/logic is currently implemented in 
the GUI side of the code and not in the engine. Fixing this is one big motivator of the current 
rewrite.

There is a second issue with the current design of GnuCash I don't know how to handle 
elegantly in a http/json context: gnucash is currently designed to be used while open. http/json 
however are stateless protocols, which mean you  would have to (re)open the gnucash 
file/database for each request the comes in. And since gnucash loads the whole file into 
memory on load, this will take a considerable amount of time for each http/json request. To 
speed this up you would need a way to interact with a gnucash running in the background on 
the server. I don't know of any way to do that currently. Perhaps I'm missing something here.

> Is part of the current work to provide a stable interface into the db
> engine (by stable I mean one that is not liable to change without good
> reason)?  One that the http i/f could drive the db through.
> 
The rewritten engine should provide such an interface yes. I don't think it is realistic to claim 
that the first release of it already will come with a stable interface, but I expect it to stabilize 
over time yes. Every side project I can think of would depend on that: a http/json interface, a full 
port to android, a scripting api (python, guile,...).

Python may even be a suitable language to write your json bindings in. Oh wait, we already do 
ship an experimental json based rest-api in python... [1]. Improvements are of course welcome.

Geert


[1] https://github.com/Gnucash/gnucash/tree/maint/src/optional/python-bindings/example_scripts/rest-api