GnuCash XML spec (for non-C languages?)

[John Ralls]

On Nov 4, 2012, at 2:05 PM, Christian Stimming <christian at cstimming.de> wrote:

> 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.


You didn't say it, but *all* of the bindings require that C library and its dependencies. The Python and Guile bindings link the library.

The problem isn't the datastore. The problem is the business logic, the code in engine and libqof that makes sure that the data in the datastore is consistent.
AFAIK there's no language-independent way to *implement* that logic, but it would be possible (though a lot of work) to *specify* the logic. The C library would be the reference implementation, but others writing for environments where C can't be used (at present that's just Android; iOS and WindowsRT do use C) could follow the specification to write a test suite and a version of the library.

The main obstacle is that the engine and libqof are a horrid tangled mess of cruft, stuffed with unused and used-only-once functions in a multiplicity of namespaces. Cleaning out that Augean Stable is many years work and is a prerequisite to figuring out which parts are the critical business logic and which are there for interfacing to other parts of Gnucash.

Regards,
John Ralls