ofx and generic import infrastructure

[Christian Stimming]

-----BEGIN PGP SIGNED MESSAGE-----

On Mittwoch, 20. November 2002 19:45, Benoit Grégoire wrote:
> So, let's start the discussion:

Sure.

> Here are the GUI services currently offered by the generic import module
> It would also need to add:
> -Destination account autoselection (auto-split creation) as part of the
> transaction matching (There is no choice but to put it on the same page,
> there are plenty of examples where two successive transactions will need a
> different match) .

Err... are you saying that the destination account matching *has* to be on the 
same page as on the transaction matching/duplicate detection? If that is what 
you want to say, then I definitely disagree... those are two different tasks 
and I can easily imagine those happening in different windows (or druid pages 
or whatever). Maybe you prefer to have both happening in one window (and I 
prefer the other) -- but if you think that there are important reasons for 
the one-window concept, can you elaborate more on that?

> -Reconcile window invocation (I see it as a list of accounts for which a
> balance was downloaded.  You check those for which you want to invoque a
> reconcile).  Since HBCI supports it, is suppose Christian wrote some code
> for this.

:-) Not really. My "Reconcile window invocation" happens in 
src/import-export/hbci/gnc-hbci-getbalance.c line 169. Not really much code, 
is it? :-) In the current HBCI implementation, the user simply gets a dialog 
window popping up in his face (line 148) asking "Reconcile now? Yes/No", and 
if the user answers yes,  the reconcile window is opened by 
recnWindowWithBalance from RecnWindow.h. That's all there is. 

> Now, I've taken a lot of heat in the past for the event based, "pop in your
> face" design of the current generic importer.  Derek and Christian want it
> to be druid based.  

Ok, this point is still up for discussion, but there are several issues with 
it, and since you asked, I'm just going to state those:

* One thing that keeps buggin me about the gnc_import_add_trans function is 
that it operates on static, hidden GUI data, which is obvious by the fact 
that it only takes one argument, the Transaction to add. IMHO the natural 
question here is "this thing adds transaction TO WHERE?" What I definitely 
would prefer here is a function like 

void gnc_import_add_trans(GenericImporter *importer, Transaction *trans);

and having the additional function

GenericImporter *gnc_import_importer_new (GtkWidget *parent);

and so on. Note that this point is still totally independent from the 
Druid/One-Window discussion. It is, however, clearly not independent from the 
point you raised about different programming styles colliding here. :-)

* Same point (different programming styles): I would kindly ask you that if 
you define function prototypes in a header file, *please* put the 
implementation in a .c file *of the same name*. Otherwise the header file 
IMHO is almost useless -- I still have to grep for the actual implementation 
of that function, which is quite a bummer. Of course this can lead to the 
fact that you create a whole lot of header files, and maybe some of those are 
almost empty -- but IMHO this is totally valid and only reflects the *actual* 
*real* function interdependencies/ program structure. Note that this point 
can perfectly be done during the next days, since it shouldn't change the 
behaviour of the code at all.

> To be honest, my motivation for GnuCash isn't at an all time high, and I no
> longer have 20 hours a week to spend on ofx and GnuCash as I had in the
> last 6 months.  

Well, everyone here has times of higher spare time for Gnucash, and times of 
less so. I'd just like to add one comment about that you worked on your code 
*alone*: I spent all summer fighting with the OpenHBCI programmers about API 
questions, which mostly were due to different coding styles (literally -- 
Martin Preuss will easily confirm that). If I had joined you and worked on 
the same code parts as you did, I would've first needed to start such fights 
all over again (the above two points are really easy ones :). I eventually 
decided that the overall outcome for the project is probably higher if I just 
let your code alone (and IMHO results are confirming that). In other words: 
You shouldn't feel disappointed because nobody else is editing the files you 
do -- instead, this has just proven to be the most effective way of dividing 
up the work, especially in OpenSource projects. Not doing so (i.e. editing 
the *same* files) immediately requires a whole different level of 
understanding and communication, which IMHO might be necessary for a big, 
multi-purpose API (OpenHBCI) but not really for one part inside a big 
application. Gee. I'm pretty sure we'll come to a nicely working application 
in the end. Thanks for your comments.

Christian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iQCVAwUBPdwLP2XAi+BfhivFAQH6nwQAmjec2UjHpNCrhBKk+PwP5s9cuZjiVs1e
koryGnXT7o5CKRych/ezq/txoxQ32H0+MCR3hlapQg4pKGjTnAXA1Vjrbt3/GdiA
vxW+PFzDy2AjHrBXEk41b1/wWbos5u8xz+gp+XkgqK7hYlXAJU/mVv8Za26ozVml
E23gkZIyqUM=
=Tnjy
-----END PGP SIGNATURE-----