Request for feedback

[Anthony W. Juckel]

On Sun, 2001-11-11 at 07:42, Bill Gribble wrote:
> On Sun, 2001-11-11 at 00:00, Anthony W. Juckel wrote:
> > Recently I've been mulling over a way to rework the current transaction
> > import code to make it a little more generic.  I noticed a comment in
> > src/import-export/qif-io-import/qif-objects.scm stating a desire to have
> > the code re-worked into GOOPS classes, so I've started with that.
> 
> Youy should probably start out by looking at
> src/import-export/qif-io-core, which is the "next generation" importer
> I've been working on. 

Oops.  Sorry, that was a typo in my email.  qif-io-core is the module
that I started looking at, and it was within qif-objects.scm that I saw
a reference to creating GOOPS classes.  

> I don't think it's a good idea to depend on GOOPS in the gnucash core
> right now.  We made a decision as a group not to use GOOPS because it's
> not well supported by the versions of guile that Red Hat users have
> available.  I personally would like to start, but I think we should wait
> at least until Red Hat ships something other than guile-1.3.4 with their
> current release. 
> 
> If you're a Red Hat user and are using guile with no problems, maybe
> it's time to reconsider. 

Well, I'm having no problems with GOOPS on my system, but I'm running
Debian.  Does anyone know why RedHat is not yet supplying a recent
version of guile?  

> > hope is to add a layer of abstraction between the file type and the
> > gnc:xtn code to make it relatively easy to add a new import file type.  
> 
> I think you're on the wrong track.  Every import format will have very
> different limitations and information shortfalls and will need different
> GUI front ends, and different processing. I advise against trying to
> take the current QIF code and make it a generic importer.

I think you may have misunderstood what I meant.  My intention isn't to
take the QIF import code itself and generalize its file parsing.  My
intention is to separate qif-io-core code into two layers, one which
does the translation of qif-file->gnc:xtns, and another which takes
those gnc:xtns parsed from the input file and figures out a way to map
those incoming transactions into current/new accounts, does duplicate
checks, etc.  So, the current qif-io-core would just be separated into
two parts.  Those that depend on qif itself (which would be seperated
into a file-format specific class), and those that do not (or at least,
should not, which would belong to the superclass).

> I think it's a good idea to use more generic tools for certain parts of
> the import process, such as eliminating duplicate transactions.  In the
> qif-io-core code, the major change I made was to convert the QIF
> transactions into gnucash transactions as early in the process as
> possible, allowing most of the logic about matching with existing
> accounts and transactions to be done by reasoning on gnucash
> transactions rather than an intermediate form.  That would allow the
> same mechanisms to be used by multiple importers. 
> 
> b.g.
> 

This is exactly the same methodology that each of the defined import
subclasses should follow:  take the input file, and convert it to
gnc:xtns, then pass this list of gnc:xtns on to the generic importer.

Is it necessarily true that each file would need a seperate GUI
process?  I have been assuming that the only parts necessary for the GUI
are file selection, account mapping, and duplicate checking, but I,
admittedly, use a fairly small subset of GnuCash's functionality (I
simply track a few checking and savings accounts, as well as
expenses...no currency conversion or investment managing).

Like I said, I'm new to all of this, so I'm just throwing ideas around,
trying to get a feel for the situation.

Anthony W. Juckel