discussion generic import design

Derek Atkins warlord@MIT.EDU
07 Nov 2002 12:52:22 -0500


Christian Stimming <stimming@tuhh.de> writes:

> >         typedef enum {
> >                 GNCIMPORT_MATCH_PAYEE = 1,
> >                 GNCIMPORT_MATCH_MEMO,
> >                 GNCIMPORT_MATCH_CATEGORY,
> >                 GNCIMPORT_MATCH_CLASS,
> >         } GncImportMatchType;
> >         Account* gnc_import_find_map_account(GNCBook*,
> > GncImportMatchType);
> >         void gnc_import_add_map_account(GNCBook*, GncImportMatchType, Account*);
> 
> 
> but these prototypes don't have any char* anymore, so there's nothing

Oops, that was an oversight on my part...  I meant to have"

Account* gnc_import_find_map_account(GNCBook*, GncImportMatchType, const char*);
void gnc_import_find_map_account(GNCBook*, GncImportMatchType, Account*, const char*);

> to match against. I guess the point is much more general here: Against
> what should that find_dest_account match? If we want to match against
> *one* string, then one char* argument as proposed by Benoit is
> enough. On the other hand, I guess that one string doesn't really fit

A reasonable question.  I was going under the assumption that each
import module could prioritize the map type and would match against
the first non-empty string.  For example if the Qif Category was
empty, try the Payee.  If the Payee was empty, it would use the Qif
Memo.  If that was empty, perhaps try the Qif Description.

> the data that we have. In HBCI, I have definitely 2-3 different
> strings with slightly different meanings. All of these 3 strings can
> be used for matching, and ideally I can tell a descending order of
> matching importance. (Example: "transaction description", "transaction
> memo", "recipient's name"). It would *not* work well if we just toss
> different strings into one long string, since that doesn't pay
> attention to different levels of matching importance. So maybe we just
> agree on the number of different strings, and I'd propose two.

I wasn't proposing that.  I was proposing an ordering (imposed by the
import module) on the various strings..  Although I'm thinking that
may not be reasonable..

> On the other hand, the name of those strings in the protocol-specific
> code (i.e. payee, memo, category etc.) IMHO doesn't matter at all, and
> of course those names are different in HBCI than they are in QIF or
> OFX.

Well, how many potential strings are there, and in what order do you
propose them?  Besides, this API is the _STORAGE_ API, not the UI API.

> That would result in
> 
> Account * gnc_import_find_dest_account(GncImportMatchMap *map, char
> *important_textkey, char *less_important_textkey);
> void gnc_import_matchmap_set_dest_account(GncImportMatchMap *map, char
> * important_textkey, char *less_important_textkey, Account *
> dest_account);

Why limit yourself to two match strings (certainly for the GUI matcher
that is the case)?  Why not be able to define a list of (typed?)
strings for matching?  For example:

Account* gnc_import_find_dest_account(GncImportMatchMap *map,
         GncImportMatchType string_type, const char* textkey,
         ...);


However, at this point it is starting to sound a lot like a rule-based
match, and frankly that's a LOT of work.  Do we want ultimate
flexibility, or do we want simplicity?

Another question: should there be a map per account?  In other words,
should the PAYEE "foo" when importing transactions in account A map to
the same PAYEE "foo" when importing transactions in account B?  I'm
not convinced they should.  That would imply a "source account"
argument as well.

> Regards,
> 
> Christian
> 
> PS: /me is away from email until Sunday, Nov 10.

-derek

PS: I'm going to be away until the 10th, too..

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available