LibOFX

[Thomas Baumgart]

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 <thb at 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 at gnucash.org
> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 225 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20160923/8003b29f/attachment.sig>