GnuCash XML spec (for non-C languages?)
christian at cstimming.de
Tue Nov 6 05:22:00 EST 2012
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...
More information about the gnucash-devel