Will GnuCash ever work for me?

[Derek A. Neighbors]

>
>
>p.s. However, you are right in another way, and perhaps we goofed.
>
Well the real issue, is it seems from this list, that people arent 
willing to upgrade.  I have heard more than one person say, "Im gonna 
stick with Quicken for now"  (I personally haved decided the same thing, 
until I get around to fixing X on my woody box).

However, my interest comes not only as a user but as a developer.  I was 
hoping to make some headway on getting GNUe to talk to GNUCash as a 
backend.  In light of the current situation, it makes it difficult 
seeing how I cant get current GNUCash to work and wouldnt want to 
venture trying to get GNUe folks to get it working. :(

I also watch with great interest because at GNUe we are facing some 
similar decisions, so Im hoping to learn from this.  We have some 
features that would require us bumping our 'dependencies' to versions 
that are more 'bleeding' edge.

>When we added graphing and print support, we might have done
>some kind of #ifdef HAVE_PRINTING so that maybe we could create
>binaries with fewer library dpendencies (and fewer features). But ...
>does that mean we should have two or three times as many installable
>binaries?  a 'gnucash-minimal' binary, with major dependecies ifdef'ed
>out, and another, with everything turned on?  Almost nobody does this.
>
Could you not make each of these 'components'.  In the microsoft world 
and now in the gnome world this is becoming common staple.  In use of 
(activeX, dll) or shared objects.  I would assume this is advantegeous 
anyhow.  This way you could modify Graphing or Reporting Support by just 
upgrading a shared object opposed to having to patch all of gnucash.  

Just dont do what gnome has fallen into and make that another plane of 
dependency hell that respects no boundaries of backwards compatiablity. :)

>The final choice is to use dynamcially loaded extensions.  Already do
>this with the potgress backend.  Gnucash binaries compiled --with-sql 
>will run just fine on machines without postgres, because its just a dll.
>
Ah, see above, this is what I suggested. :)

>I beleive that the other coders are restructuring gnucash-1.7 to have
>this kind of a dynamcially loaded plug-in system.  This way, if feature
>whiz-bang is a plug-in, and the required supporting libraries aren't
>installed, then the plug-in simply won't run.  Of course, if you want
>all the plugins to work, you'll still need to install/upgrade like crazy
>...
>
Bingo, but now it becomes an optional thing.  Which ever way you choose, 
if it works, you should write an article explaining how you did first 
time and the issues and how you did the second time and the issues.  I 
think this is something all developers face, but PARTICULARLY free 
software developers are starting to face.  Mainly because as you stated 
in an earlier mail we dont have a 'distrubtion cycle' time buffer like 
prop software vendors do.

Derek