Regarding KtoBlzCheck GSoC project

[Ralf Habacker]

Am 25.03.20 um 20:36 schrieb Prasun Kumar:
> Dear Sir,
> Thank you for answering the questions. I have some more.
> For the API part, should I use the KMyMoney implementation suggested by 
> you(https://cgit.kde.org/kmymoney.git/tree/kmymoney/payeeidentifier/ibanandbic?h=4.8) 
> as a reference?
yes.

It may also be possible to use that implementation according to the 
license under which it was released to have a drop in replacement.

When I looked at the code, I saw a hint that this implementation is not 
thread-safe, see 
https://cgit.kde.org/kmymoney.git/tree/kmymoney/payeeidentifier/ibanandbic/bicmodel.cpp?h=4.8#n34 
and need changes to fix this.

To change the license, for example to LGPL, you need to contact the 
author Christian Dávid.

> Secondly, for adding support for additional countries, should these come 
> under iban or should I create separate files and classes for each country?

aqbanking uses file sets for each country (see https://github.com
/aqbanking/aqbanking/tree/master/src/libs/plugins/bankinfo/generic)

$> rpm -q -l aqbanking | grep bankinfo
/usr/share/aqbanking/bankinfo/de/banks.data
/usr/share/aqbanking/bankinfo/de/bic.idx
/usr/share/aqbanking/bankinfo/de/blz.idx
/usr/share/aqbanking/bankinfo/de/namloc.idx

and kmymoney uses sqlite databases for each country

$> rpm -q -l kmymoney | grep bankdata
/usr/share/kde4/apps/kmymoney/ibanbicdata/bankdata.ch.db
/usr/share/kde4/apps/kmymoney/ibanbicdata/bankdata.de.db

With gnucash I only found a dependency to ktoblzcheck, which means it 
uses different files for each country.

Regards
Ralf


> Thanks,
> Prasun
> 
> On Sun, 22 Mar 2020 at 19:32, Ralf Habacker <ralf.habacker at freenet.de 
> <mailto:ralf.habacker at freenet.de>> wrote:
> 
>     Am 20.03.20 um 19:28 schrieb Prasun Kumar:
>      > Dear Sir,
>      > I am drafting a project proposal for GSoC and I have a few questions
>      > regarding the project.
>      >
>      > In the KtoBlzCheck cmdline tool, there is an option of taking the
>      > bankdata file as an input from the user. In this case, should we use
>      > the text file format as being done right now if I am not mistaken
>      > because the user should not be compelled to provide a sqllite db
>     as an
>      > input file?
> 
>     the text format file has some disadvantages:
> 
>     1. It provides no date range (currently several text files are required
>     to support valid date range and
> 
>     2. it does support multiple languages as it is required by kmymoney
>     https://cgit.kde.org/kmymoney.git/tree/kmymoney/plugins/ibanbicdata?h=5.0
> 
>     As this GSOC project is to replace raw bank data text files by an sqlite
>     data base., the command line tool should get an option to use a sqlite
>     database from a custom path.
> 
>     Regards
> 
>     Ralf
>