Have you seen those emails, especially my remark about an existing mt940 parser inside the OpenHBCI library?
Best, Jan-Pascal van schrieb:
One question to start with: the parser API can be made in a number of ways:
1. With callback functions. You define functions like mt940_start_transaction(), mt940_transaction_memo_field(), mt940_opening_balance(), which get called in a specified order.
This kind of API is not encouraged in gnucash and should not be used.
2. The parser reads the entire file, turns it into a data structure and returns that data structure. Makes for a cleaner and simpler API, but may drive up memory requirements if mt940 file being read is large
This is the kind of API that e.g. OpenHBCI offers. I would recommend this kind of API for any external stand-alone library.
3. The parser just calls back with every "statement" or transaction.
The *parser* calls back? I.e. the external library calls a callback function? This would require callback functions just as proposal 1. does. I would not encourage such an API as well, but I might have misunderstood what this actually means.
Christian
I think I'll choose the last option, unless you have argument for another choice?
Then there is the problem of supporting the different banking format. I've thought of a way to do this cleanly, but it will probably come down
to first filling in the transaction using a default interpreter and then,
for known bank-specific formats, calling functions to do the dirty work.
This means that the bank specialties are hard-coded in the importer module.
Please let me hear your opinions (and get those anonymized MT940 files coming!)
Jan-Pascal
_______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
