GnuCash XML spec (for non-C languages?)

[Christian Stimming]

Am Donnerstag, 1. November 2012, 09:43:30 schrieb John Ralls:
> On Nov 1, 2012, at 9:32 AM, Geert Janssens <janssens-geert at telenet.be> 
wrote:
> > On 01-11-12 17:13, Derek Atkins wrote:
> >>> Also, what is the policy of GnuCash towards manipulating the XML.
> >>> 
> >>> Is modifying the XML also actively discouraged?
> >> 
> >> Yes.  All data 'writes' should only happen through the GnuCash API.
> > 
> > Which means there are currently 3 supported ways to modify the data:
> > - using the GnuCash application's gui
> > - you can write a guile/scheme script that uses the GnuCash API
> > - if python bindings are enabled on your platform you can also write a
> > python script that uses the GnuCash API.
> There's a fourth: You can write a program in any language which can load a C
> library.

We used to be somewhat proud of this statement - being able to offer a C 
library that can handle the data store correctly. However, I think the times 
have changed. By they way, the gnucash API isn't only a C library, but 
instead, it's a C library requiring glib - any new platform would first have a 
glib being ported to it.

Today, we have all those new mobile devices. They might even allow C 
libraries, but if they do, it would be a C library for specific architectures 
with significantly smaller target audience than the whole mobile platform in 
mind. Or in other words, one would have to cross-compile a whole set of 
different C libraries to cover all the mobile devices using a particular 
platform. And for the gnucash API this all wouldn't even work as long as there 
isn't a glib on that platform!

Because of this new situation today, I think it would be quite useful to be 
able to modify our original point of view concerning access to the datastore. 
I think it would be quite useful to find some sort of datastore access layer 
that is *not* forced to be a C library. In fact, it shouldn't be tied to any 
specific programming language. If it were possible to postulate the structure 
of the datastore in such a language-independent way, it would enable other 
languages and platforms without C libraries to offer gnucash data display and 
manipulation. Such as Ngewi's Android app, directly accessing a SQL database 
with gnucash data. Or any app on any of those other well-known mobile 
platforms. They all have in common that it is impossible to use the gnucash C 
library. They all have in common that it's a huge improvement for users to be 
able to do their bookkeeping also from those devices.

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.

Regards,

Christian