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 

Background information: today, KMyMoney has its own implementation of the OFX 
interface being based on LibOFX and an online interface to 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).



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

Reply via email to