GnuCash XML spec (for non-C languages?)

[Colin Law]

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.

Colin