Gnucash architecture and dependencies

[Daniel Vainsencher]

Since I am not on the list, please cc me on any replies.

[Perl isn't used in the project, as much as the project uses an external
perl module]
Ok, then that's less of an issue.

> 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.
I happen to like scheme. I don't know how Guile is as a technology to
work with, but it has the advantage that it seems lively as project, and
seems suited for your goals. Don't see a reason to drop it - I was
assuming it and perl were living in the same niche.

> 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.
I agree - I am not saying to make grandiose plans and start working at a
tangent to your users. The right way to do refactoring is a little bit
every day. That's especially important in dealing with big refactorings
- do them in small bits. Eventually, new developers coming in will see a
project that shows it cares about simplicity, which is the most direct
and effective way to encourage new developers.
 
> > 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...
BTW, you mention in the article implementing a wiki in a way that made
me think you might be talking about writing one. There are hundreds of
existing implementation, in C, in Scheme, in Smalltalk... Just pick one
and install it. It makes updating and improving the site so much easier
that it is worth it the people doing the updating remain the same ones.
And move all fast changing information to it, so anyone can update it -
then users are unlikely to wait to the core developers to update it -
they'll do it themselves.

> > 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.
I'm not saying to make it a monolithic application - somewhere in
between. Read on.

> 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) 
These are all interface technologies. That isn't a coincidence.
Interfaces, because they are at boundaries between you and another
project, suffer more bitrot than other code. They are harder to find a
maintainer for, because they require knowing more than just your
project. So I'm just saying that you should be very selective about what
interfaces you decide to include in the project. QIF sounds strategic
(allowing users to convert). The others I don't know enough about to
say, but every interface you can lose will make your life simpler.

[core feature of DB is no information loss, no save]
> The interim solution in 1.8.5 is the logfile player I wrote.  
Cool!

> The plan in 2.0+ 
> is to use en embeded database, so save will go away.
Ok. As long as you don't need to maintain it yourselves :-)

> > 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.  
Unless you have something simpler that fills your needs, XML is a
standard technology with lots of libraries. Might not be worth dumping.

> -Dumping guile just to replace it with another scripting language is neither 
> realistic nor really usefull.  
Agree.

> -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.
All sounds good. Especially if the gnumeric engine isn't forked, so that
you keep sharing the maintainence. This might be enough - don't drop
something you need, just drop everything you can live without replacing.
It'll be easier for the developers the project has to deal with what
remains, and it might actually make the project a more inviting place
for new developers.

[Importance of non-home users is that they bring their own coders]
Ahh. I missed that. Nevertheless, seems to me you already have less eyes
than balls to keep them on, so consider each connection carefully.

Anyway, thanks everybody for working on a great project. First financial
software I use, and I find it quite helpful. Using it has helped me
develop my ideas about how to think of money.

Daniel