LibOFX

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

LibOFX

John Ralls-2
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?

Regards,
John Ralls


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: LibOFX

Thomas Baumgart-2
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
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: LibOFX

Christian Stimming-4
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 <[hidden email]>:
>
> 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
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: LibOFX

Thomas Baumgart-2
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 <[hidden email]>:
> >
> > 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
> > [hidden email]
> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

signature.asc (233 bytes) Download Attachment