Gnucash architecture and dependencies

[BenoitGrégoire]

On Monday 11 August 2003 16:58, Daniel Vainsencher wrote:
> Hi. I read a mail by you that was posted to LWN, and thought to offer
> some thoughts that are a bit different.
>
> As a (very grateful) user of GnuCash, and a developer on other projects,
> here is why I would be wary of putting the time to learn the development
> ropes and join the project - low conceptual integrity.
>
> The dependecy list is not a problem, it is a symptom. In fact, for me it
> isn't any kind of practical problem (thanks to Debian :-). Your deep
> engines are in C. You have a perfectly powerful scripting engine in
> Guile, but also use Perl scripts. Why? so much stuff to learn before
> mastering the system...

The only perl in the current codebase is that we call the Finance::Quote 
module to get stock quotes and currency exchange rate.  Someone starting to 
work on GnuCash is unlikely to encounter it.

> If you want to attract developers, you should have coherent
> architecture, which includes decisions on what technologies you tie
> yourselves to, and which you don't. Part of the web site are really

The project is over ten years old.  It once used perl as it's scripting 
engine, and long before any of the current developers got onboard a decision 
was made to switch to guile (scheme).  Do we sometimes regret it?  Yes.  Do 
we want to de-emphasize scheme from some parts of the code?  Yes.  Would it 
be a good idea to get completely rid of it?  Not at all.

As for the architecture, it's not too bad, and it's actually getting cleaned 
up as a byproduct of the gnome 2 port.  In an ideal world, we would a fair 
amount of time to do code refactoring.  But until we do everything I outlined 
in the article, major organized refactoring (such as reworking dependencies, 
or major architecture changes) which do not solve an immediate problem are 
not likely to happen, and likely to do more harm than good in some cases.

> scary - for example, the goals page includes release information - and
> it quite out of date. It also includes a quite wrong description of the
> MVC pattern - which doesn't instill much faith in the benefit its use
> brings to the project.

Well, I mentioned in the article that the web site is is out of date and 
misleading, so I fully agree...
 
> The "loose confederation of cooperating components" is probably one of
> the reasons you're seeing so much bit rot - reliance on fragile
> interfaces is what futile maintainance work is made of.

Realistically for such a large code base, a monolithic application 
(architecture wise) would be a nightmare.  We do merge or split modules when 
it makes sense and eases maintainability.

The general architecture is fine (tough it suffered from lack of project 
management and a half implemented module subsystem).  The reason that we are 
getting so much bit rot is usually that a complex but peripheral module 
(postgres backend, qif-io-core, perl external bindings) lost is author or 
maintainer, and is no longer well understood.  In the case of the postgres 
backend, someone (Matthew Vanecek) adopted it.  In the case of the qif 
importer, we reluctantly maintained it's spaghetti code to this day, because 
no one could figure out how to plug it's planned replacement (qif-io-core, 
ready years ago, only needed a GUI) in the new import framework.  So now it's 
being rewritten from scratch by Derek.

> About the multi user bit - while having a persistent store that many
> applications can access is a nice idea, I am not sure the implementation
> plan is very well thought out, since it seems to me the most obvious
> first thing that should be done in this area is the elimination of the
> "save" function. If you want to convince users that their data is safe,
> simply never lose any. I know logging is done, but in times that a power
> shortage happened, I've had to read and redo those logs manually.

The interim solution in 1.8.5 is the logfile player I wrote.  The plan in 2.0+ 
is to use en embeded database, so save will go away.

> In short, I think you need to consolidate - decide what technologies are
> earning their keep and which are simply a headache to work with, and
> dump some of them. Same for architectural ideas - choose a few goals,

Sincerely, I don't see much to dump.  
-Technically we could dump XML eventually.  
-Dumping guile just to replace it with another scripting language is neither 
realistic nor really usefull.  
-Dumping g-wrap or alternatively swallowing it's codebase is a good long term 
goal.  
-GtkHTML has it's problem, but is absolutely essential for reports.
-Libghttp can be dumped (if it hasn't already), to my knowledge, nothing in 
current working code requires it.
-Guppi no standalone replacement for this exists, but we are talking with the 
gnumeric developers to see if we can spinoff their graphing engine.  Rolling 
our own from scratch would be a monumental waste of time.

> and do those completely. You mention letting other projects interoperate
> with your engine. Does this really help the project gain a large user
> base? I think it is marginal - most of the features GnuCash needs for
> home users need to be tightly integrated anyway. OTOH, import/export
> from the most popular existing formats is critical, unless you want to
> create your own user base from new users, which is hard work (lots of
> newbie questions that don't know how to do accounting). So choose your
> main "market", and target those, and make that completely solid. Then
> you can widen your sights.

What you say is true.  Unfortunately, most home users can't code, and most of 
those who do do not see financial software as something sexy to work on.  Our 
primary "market" has truly always been the home user, and will most likely 
remain so.  (Let's leave the double entry flames for another day).  

Interoperating with other software isn't primairily aimed at increasing our 
userbase (tough if it works, it probably will), it's aimed at pooling 
developer ressources.  Those who work on software that would interact with 
gnucash may not be be legions, but by definition they:
1- Know how to code
2-Have some kind of interest in financial software development.

Thanks for your feedback,
-- 
Benoit Grégoire
http://step.polymtl.ca/~bock/