Design Decisions

[BenoitGrégoire]

On Tuesday 19 August 2003 14:54, you wrote:
> On Tue, 2003-08-19 at 16:54, Benoit Grégoire wrote:
> > Yes, but they sure as hell didn't start over.
>
> Redesigning and rewriting is not 'starting over'.  It's identifying the
> parts you want to keep, the parts you want to improve, and the parts
> that need either rewriting or scrapping altogether.
>
> Perhaps I should say 'ruthless evolution' is a more accurate term.

In that case we are in agreement, except I guess for the ruthlessness of the 
thing.  I wouldn't want us to revisit the QIF importer fiasco.  (Written once 
with a poor design, Started over with everyone's encouragement and  taken to 
95% completion, said to be much better.  Developper leaves, no one really 
understand replacement code, so code is never deployed.  Now first codebase 
still (reluctantly) maintained while third implementation in progress.

Basically before scraping code, we need to make sure that:
-The ramification of scraping it are well understood.
-We can replace it fully in a timely manner.

Otherwise, if it ain't broke, fix something that is...

> I read the "state of the gnucash project" page before I posted that
> email.  There was very little specific content on prospective
> development of the codebase other than 'we have problems', import/export
> and it's not clear how much of a priority the Gnome2 port is.
>
> None of that addresses the problem of attracting developers.
>
> > Yes, stop discuraging developers who want alternate bindings.  See the
> > link.
> >
> > Also, to my knowledge, the perl swig bindings predate scheme in gnucash,
> > were implemented by (or at least with support form) the core developers
> > and have bitroted from non-use.  But we do hope someone will revive them
> > and apparently it wouldn't be hard.  They are also mentioned in the link.
>
> The link only mentions they have bitrotted.  There is no mention of what
> should be done about it.
>
> Let me be more specific.
>
> At the moment, you have:
>
> GnuCash core <> Scheme (Guile)
>              <> SWIG
>
> I'm saying (unless my understanding of the core/scheme relationship is
> utterly incorrect) it should be:
>
> GnuCash core <> SWIG <> Scheme (Guile)
>                         Any other language
>
> That's not much more work (other than getting the SWIG bindings up to
> date).
>
> You'd only be maintaining 1 interface, only it would be GCcore <> SWIG
> rather than GCcore <> Scheme.  Scheme is still supported fully, just
> through SWIG rather than directly.  There's very little extra work
> required, yet you're satisfying your major detractors and supplying a
> Perl/Python/Ruby interface.
>
> Have I gotten this massively wrong?

Yes and no.  I think you slightly misunderstood the focus of that first 
article.  The article focused on our current problems,  and was mostly meant 
as a reflection piece to reach a common understanding of our problems.  
Specific projects to address them will be the focus of the second article, 
that is delayed because I am still drowning in emails from the first.  The 
article didn't talk about the gnome port because apart from the fact that 
it's a huge undertaking, it's still a part of the project that goes well.

As for SWIG, the thing is that the scheme "interface" is pervasive and mostly 
focussed on internal needs.  It covers areas that we would not really want to 
expose to the world, such as internal GUI data.

Now if we can use swig to generate our bindings to to the engine at runtime in 
multiple languages, it would be REALLY cool! 
-- 
Benoit Grégoire
http://step.polymtl.ca/~bock/