Thinking Big Picture (Re: Challenging python coders ...)

David Eisner deisner at gmail.com
Tue Jan 11 17:49:55 EST 2011


011/1/11 Christian Stimming <stimming at tuhh.de>:
> you do realize that you're discussing something completely different, don't
> you? I proposed to experiment with a python-written GUI on top of the existing
> wrappers, which means they will re-use the existing C engine code (100k LOC)


Your thread did kind of get hijacked there.  Sorry about that.

But while we're talking about changing the architecture of GnuCash, I
do think that this might be a good time to discuss how we can do so
while leaving the door open for satisfying, one day, the feature
requests that repeatedly arise on the list.

I'm about the last person who should be discussing this since, with
the exception of a minor bug fix in a report, I haven't hacked on
GnuCash.  But I won't let that stop me. :-)  I'm really just thinking
out loud. I hope somebody with more knowledge can say whether this is
a tree worth barking up.

Here are some of the big features people seem to want:

   * Standalone Desktop app (we already have this)
   * Web-based app
   * Mobile app (iPhone/Android/...)
   * Multi-User Access
   * Easier Development
   * Better Reports

What kind of architecture would make this possible?  I realize there
are limited developer resources, so you have to choose your battles.
It would be nice, though, if GnuCash could be refactored so it would
be possible to implement some of these items requests, and at least
make the rest possible at a future date.

I haven't really thought this out.  The following is more an attempt
to give the flavor of the kind of thing I'm imagining.  The pieces
might include:

   * Data Store (SQL db)
   * GnuCash Engine (C or C/C++)
   * Report Engine (probably utilizing HTML/CSS/<canvas>)
   * Qt-based front end
   * Web front end (with mobile optimized version, perhaps)
   * Android front end
   * iOS front end

The idea would be that the components could be combined in different
ways.  With just the Data Store + GnuCash Engine + Report Engine +
Qt-based front end you get the Desktop app.  Or you have an Apache
server + GnuCash Engine + Report Engine + the Web front end talking to
a data store (either local or remote) to give you the web app. Maybe
the desktop app can talk to a remote data store (specified with a
URL/password).

A mobile-optimized web front end might satisfy some of the
Android/iPhone users.  On the other hand, it might be nice to have a
native Android app (say), with more limited functionality.  It could
let you enter transactions even when you're offline (provided you've
synced at least once with your data store), and then try to submit
them when you have network connectivity again.

Figuring out what pieces are needed, what their interfaces would look,
and doing it in a secure and performant way would itself involve a
fair deal of effort, even if only some of the pieces are built.
Furthermore, you don't want to start from scratch and throw out years
of development.  After all we have GnuCash now, and it works.

This may be more trouble than it's worth, and a more incremental
approach is probably a better way to go.  But I just wanted to put
this out there while I'm thinking about it.

-David

-- 
David Eisner     http://cradle.brokenglass.com


More information about the gnucash-user mailing list