GnuCash XML spec (for non-C languages?)

[Colin Law]

On 4 November 2012 22:31, John Ralls <jralls at ceridwen.fremont.ca.us> wrote:
>
> 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.

That is a valid argument against using cloud storage but it does not
apply to a home server.

Colin L.