On Nov 6, 2012, at 1:30 AM, Geert Janssens <[email protected]> wrote:
> On 06-11-12 00:57, John Ralls wrote: >> On Nov 5, 2012, at 1:55 PM, Geert Janssens <[email protected]> wrote: >> >>> On 04-11-12 23:05, Christian Stimming 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. >>>> >>>> Regards, >>>> >>>> Christian >>>> >>> I agree with your point of view that there is a whole new breed of devices >>> flooding the market for which GnuCash as we know it is not really well >>> suited, both from a technology point of view (how portable is our code ?) >>> or in flexibility to adapt to new form factors. >>> >>> I'm a curious to learn what our options are to realistically improve this. >>> Below is a lot of thinking out loud about the situation we are in now. >>> >>> Reading the above, my first urge tends to be "rewrite the whole thing from >>> scratch, except cleaner and more perfect in a platform independent way". >>> Which I immediately reclassify as not very realistic considering the >>> limited time the current team of volunteers has to spend on the project. >>> >>> 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. >>> >>> An important factor to help evaluate this in my opinion is to look really >>> close at the way the new form factors work. GnuCash has always been and >>> still is a desktop application, and firmly relies on that desktop paradigm. >>> I mean, it is a tool meant to be used by one user at the time and intended >>> for local data stores. Yes you can use a remote database as a data dump. >>> There's no intelligence in the database layer at all though. And yes, you >>> can access a datafile on a network share. But those are all part of a >>> desktop experience. Tablets (and smartphones) on the other hand are heavily >>> vested in a cloud metaphor. Like it or not. Very few apps will let you >>> choose where on the tablet you want to store your data. Most of them are >>> backed by a web service which conveniently "take all the complexity of file >>> management out of your hands". People used to the desktop metaphor tend to >>> find that ridiculous, but my observation of less computer literate people >>> around me confirm this wo! rks. Such people really like the idea of just tapping an app, passing a one-time setup consisting of entering an e-mail address and choosing a password and go on happily using the app. They are not interested where their data is stored and that it's most likely not on the tablet itself. >>> >>> So far the general idea. Where I want to get at is what Colin suggested: if >>> you want to do something in the tablet world, you have to think the tablet >>> way, which means "cloud". For clarity, when I say "cloud" I mean your >>> tablet app itself should be light-weight and be backed by a powerful online >>> service. This service can run either hosted on some public cloud provider, >>> or on your own server at your office. That's irrelevant here. So I'm not >>> against the idea of a web frontend for GnuCash. >>> >>> So that is one way to see GnuCash on tablets: a web service with an >>> associated client app on the tablets. This would allow us to reuse much of >>> the existing code base (the engine). Ideally, that would be split into a >>> separate library with a well defined api. This api could then equally be >>> used for the current GnuCash desktop application, a web frontend, perhaps >>> even a full featured GnuCash for tablets application on tablets that run C >>> natively, and so on. As far as I'm concerned I would even love to see our >>> collegues (like KMyMoney, Skrooge,...) use our own library to import/export >>> from/to gnucash. The same api could also be exposed via scheme and python >>> (which are there now already, but can then be cleared up as well), ... >>> >>> As for the work involved. It is still huge. I wouldn't know what is >>> required to create a web interface on top of GnuCash. But there are at >>> least some challenges I can think of: >>> * basic web protocols such as http are stateless, how does the server know >>> which client wants to access which data file ? Cookies ? Perhaps. >>> * Web clients generally don't inform the server they have finished. Each >>> server interaction is more or less atomic on it's own. So how will the >>> server know a data file can be closed, has to be saved, ... All desktop >>> metaphors that are clumsy in a web interface world. Xml is useless as a >>> backend in this context. >>> * The database backends go partly in the right direction, but still aren't >>> adapted to be used as web server backends. The current sql backends still >>> load the whole dataset in the beginning because the GnuCash engine was >>> never written with a database as backend in mind. This would have to be >>> fixed. >>> * Simultaneous multi-user access is definitely a basic requirement. Even if >>> there's only one real user, he/she will most certainly want to access the >>> financial data from both the tablet and the desktop without having to >>> remember to log out on the one first before logging in on the other. >>> And so on... >>> >>> Anyway, that's the option I see currently. I'd love to hear other ideas >>> though. >> OK. >> >> Engine unit testing has gotten set aside this summer by my realization that >> we're running into the 2038 date issue rather sooner than we expected, >> because it's breaking long-term SXes. Dealing with that turns out to be a >> lot of work, but I hope to wrap it up by the end of the year and get back to >> testing Engine and QOF. > I wasn't aware of your work on the 2038 date issue. I have just discovered > your fix-dates branch on github. That's a very big work. And I didn't know OS > X and Windows aren't looking ahead that far. I'm slightly surprised glib has > has no provisions for this. After all that is an important portability > library for writing portable applications in C. But I'm sure you have looked > around before starting your own implementation. Oh, OSX and Win32 have their own 64-bit date-time APIs, they just haven't pushed them on to time_t. I *am* using GLib: That's where GDateTime comes from. However, GTimezone only worked with Linux (because it uses the TZif2 with 64-bit DST intervals) until I fixed it in GLib 2.34.1 to work with TZif and therefore BSD and OSX [1]. The implementation for Win32 [2][3][4] is a lot more involved, so it's going to go into GLib 2.36. Fortunately Gnucash needs only a small part of it, and I'd written the work-around for that part before Arnel got started. Regards, John Ralls [1] https://bugzilla.gnome.org/show_bug.cgi?id=631382 [2] https://bugzilla.gnome.org/show_bug.cgi?id=683998 [3] https://bugzilla.gnome.org/show_bug.cgi?id=686128 [4] https://bugzilla.gnome.org/show_bug.cgi?id=686184 _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
