On Nov 4, 2012, at 2:22 PM, Colin Law <clan...@googlemail.com> wrote:
> On 4 November 2012 22:05, Christian Stimming <christ...@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-ge...@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 _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
