Christian, On Friday 23 September 2016 16:58:25 Christian Stimming wrote:
> 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? We use libofx as provided by the distros, to keep installation easy. > 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... Well, sort of an XML file. > No additional ideas here, sorry. Not here either. -- Regards Thomas Baumgart GPG-FP: E55E D592 F45F 116B 8429 4F99 9C59 DB40 B75D D3BA ------------------------------------------------------------- The beauty of standards is that there are so many to choose from. ------------------------------------------------------------- > 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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel