GnuCash XML spec (for non-C languages?)

[John Ralls]

On Nov 4, 2012, at 2:22 PM, Colin Law <clanlaw at googlemail.com> wrote:

> On 4 November 2012 22:05, 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.
> 
> A web service interface would be good.  Then one could enter one's
> transactions directly into the database in the cloud or ones home
> server from the mobile device.  No messing about with export/import.

I wouldn't go there. Most people, me included, consider their financial data to be extremely sensitive and private. The potential liability from such a cloud storage facility getting hacked is incalculable.

Regards,
John Ralls