On 4 November 2012 22:31, John Ralls <[email protected]> wrote: > > On Nov 4, 2012, at 2:22 PM, Colin Law <[email protected]> wrote: > >> On 4 November 2012 22:05, Christian Stimming <[email protected]> wrote: >>> Am Donnerstag, 1. November 2012, 09:43:30 schrieb John Ralls: >>>> On Nov 1, 2012, at 9:32 AM, Geert Janssens <[email protected]> >>> 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. _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
