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 <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.
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 works. 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.
Geert
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
