Another option would be to have a GnuCash "service" that runs on a home server and enables remote access to the GnuCash data through a well defined services API. A mobile app would implement the client side of the services API and connect to your running GnuCash service. Less to set up (no https required) but more work for us because we need to implement more. This could also enable a web service.. especially if we decide to use xml or json as the transport framework.
But writing an http service might still be easier, even if it is harder to set up for the average Joe. I suspect some people would be willing to use a web service run by someone else.. *ponders* -derek Sent from my HTC smartphone ----- Reply message ----- From: "Christian Stimming" <christ...@cstimming.de> To: "Geert Janssens" <janssens-ge...@telenet.be> Cc: <gnucash-devel@gnucash.org> Subject: GnuCash XML spec (for non-C languages?) Date: Tue, Nov 6, 2012 5:22 AM Am Montag, 5. November 2012, 22:55:32 schrieb Geert Janssens: > > 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. > > We could also try to "clean up the current Augean stable" as John nicely > puts it. I thought this was more or less what we decided to do the > previous time we did some introspection in the state of the gnucash code > base. An important first step was to write a good set of unit tests > covering all critical engine code. From there on qof could gradually be > replaced with the more standard gobject framework. The unit tests should > prevent most of the regressions. But I'm under the impression the unit > test work has stalled mostly. And if at some point in time Android will > be considered an important primary platform to run GnuCash on, we could > wonder if this work is still worthwhile ? From John's mail I understand > that ios and WindowsRT would not be an issue if we continue to work in C. Unfortunately the engine unittests don't really help for the direction of thinking here. Those unittests only cover data access through our C library (and depending on glib), and my main point is that those new devices will want to access the data through some other means but surely *not* through the existing C library. As for the general direction: In gnucash we have a giantic set of features, and most of us probably like the program because we can use our preferred subset of those features in a unified UI and with the other features still reachable if we want them. As discussed before, moving the large set of current features to a new platform is too difficult for now. However, I believe it should be possible to move a small *subset* of our current features to a new platform. Ngewi's GnucashMobile app is precisely a very good demonstration of this. This small subset will meet some user's demands and that is fine. The challenge is now to get a good data store connection between the new UI and the existing and ongoing desktop gnucash version. For Ngewi's project, he chose the easiest way of data connection: A one-way file export from his App, and import in gnucash. However, I believe there are more possibilities for data store interaction between a new program with a subset of features. That new program will only need to access a subset of the data store. As soon as we can specify the data store access for that data subset in a way independent from the C API, we can also use other languages and platform for that new data store access. Hence, even though it is still not yet realistic to find a complete specification of data store access independently from our C library, I think it should be possible to do a specification of a subset of the data. And applications that access and work on only that subset should then be possible. Such as, an Android app that access a gnucash SQL data base, and using only those specified features and data store elements. Voila, there we have our multi-user multi-platform gnucash within reach... Best Regards, Christian _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
