Re: GnuCash XML spec (for non-C languages?)

[Derek Atkins]

Another option would be to have a GnuCash "service" that runs on a home server and enables remote access to the GnuCash data through a well defined services API. A mobile app would implement the client side of the services API and connect to your running GnuCash service.  Less to set up (no https required) but more work for us because we need to implement more.  This could also enable a web service..  especially if we decide to use xml or json as the transport framework.

But writing an http service might still be easier, even if it is harder to set up for the average Joe.   I suspect some people would be willing to use a web service run by someone else..  *ponders*

-derek

Sent from my HTC smartphone

----- Reply message -----
From: "Christian Stimming" <christian at cstimming.de>
To: "Geert Janssens" <janssens-geert at telenet.be>
Cc: <gnucash-devel at gnucash.org>
Subject: GnuCash XML spec (for non-C languages?)
Date: Tue, Nov 6, 2012 5:22 AM


Am Montag, 5. November 2012, 22:55:32 schrieb Geert Janssens:
> > So IMHO the logical next step is to find some new formulation of the
> > gnucash datastore where the data manipulation is no longer solely tied
> > to a C library. I know this step isn't particularly easy, but I think
> > the time has come to no longer outright refuse such a step.
> 
> We could also try to "clean up the current Augean stable" as John nicely
> puts it. I thought this was more or less what we decided to do the
> previous time we did some introspection in the state of the gnucash code
> base. An important first step was to write a good set of unit tests
> covering all critical engine code. From there on qof could gradually be
> replaced with the more standard gobject framework. The unit tests should
> prevent most of the regressions. But I'm under the impression the unit
> test work has stalled mostly. And if at some point in time Android will
> be considered an important primary platform to run GnuCash on, we could
> wonder if this work is still worthwhile ? From John's mail I understand
> that ios and WindowsRT would not be an issue if we continue to work in C.

Unfortunately the engine unittests don't really help for the direction of 
thinking here. Those unittests only cover data access through our C library 
(and depending on glib), and my main point is that those new devices will want 
to access the data through some other means but surely *not* through the 
existing C library.

As for the general direction: In gnucash we have a giantic set of features, 
and most of us probably like the program because we can use our preferred 
subset of those features in a unified UI and with the other features still 
reachable if we want them. As discussed before, moving the large set of 
current features to a new platform is too difficult for now.

However, I believe it should be possible to move a small *subset* of our 
current features to a new platform. Ngewi's GnucashMobile app is precisely a 
very good demonstration of this. This small subset will meet some user's 
demands and that is fine. The challenge is now to get a good data store 
connection between the new UI and the existing and ongoing desktop gnucash 
version. For Ngewi's project, he chose the easiest way of data connection: A 
one-way file export from his App, and import in gnucash. However, I believe 
there are more possibilities for data store interaction between a new program 
with a subset of features. That new program will only need to access a subset 
of the data store. As soon as we can specify the data store access for that 
data subset in a way independent from the C API, we can also use other 
languages and platform for that new data store access.

Hence, even though it is still not yet realistic to find a complete 
specification of data store access independently from our C library, I think 
it should be possible to do a specification of a subset of the data. And 
applications that access and work on only that subset should then be possible. 
Such as, an Android app that access a gnucash SQL data base, and using only 
those specified features and data store elements. Voila, there we have our 
multi-user multi-platform gnucash within reach...

Best Regards,

Christian
_______________________________________________
gnucash-devel mailing list
gnucash-devel at gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel