Dear Thomas, how do you currently do the ofx import in kmymoney? Do you still use libofx as it is on source forge (or now GitHub) or do you have your own fork?
If there is any alternative available, it would be better to switch, because libofx has an extremely bad architecture. However, aqbanking will also cause significant work because it squeezes all the data through its common interface that was designed primarily for online banking, and it uses several pieces that are unnecessarily different from how the rest of the world does their coding. Isn't there any third alternative? After all, it is "only" about parsing an xml file... No additional ideas here, sorry. Regards, Christian > Am 23.09.2016 um 08:04 schrieb Thomas Baumgart <t...@kmymoney.org>: > > John et al. > >> On Friday 23 September 2016 06:17:04 John Ralls wrote: >> >> Devs, >> >> LibOFX seems to be no longer actively developed. This is a problem because >> the OFX specification is approaching the second minor release (2.2) after >> LibOFX's target version as well as because there is at least one bug >> (relating to date handling) that affects GnuCash. >> >> There is also a parsing problem with Chase Bank downloads because (in spite >> of being on the OFX committee) they've chosen to make their QFX downloads >> non-compliant. This appears to cause LibOFX to get confused about what >> data belongs in what struct member. >> >> Martin Preuss has suggested a couple of times that we drop LibOFX and use >> AQBanking for OFX/QFX processing. It would seem that the only viable >> alternative would be to fork LibOFX and maintain our own version, but we're >> already strapped for development resources so while that might allow us to >> put out a fire now and then we're not going to be able to keep up with spec >> changes any better than what's already happening. >> >> Any other ideas? > > In fact, GnuCash is not alone out there. KMyMoney is facing the same problems > and it makes much sense in my/our eyes to work with joint efforts in this > matter. > > Background information: today, KMyMoney has its own implementation of the OFX > interface being based on LibOFX and an online interface to www.ofxhome.com > for > setup purposes. Besides that, we do support AqBanking as well, since we use > it > for HBCI interfacing. So we can switch already today, but I suspect most > users > use the former version as it is a bit more intuitive and nicer on the UI > front > compared to the AqBanking way. > > Regarding development resources, the KMyMoney project is facing similar > problems, so simply forking LibOFX is not a real option either. > > Just my 0.02 (currency less). > > -- > > Regards > > Thomas Baumgart > > GPG-FP: E55E D592 F45F 116B 8429 4F99 9C59 DB40 B75D D3BA > ------------------------------------------------------------- > There are two rules for success in life: > Rule 1: Don't tell people everything you know. > ------------------------------------------------------------- > > _______________________________________________ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
