GSoC project discussions

[Ralf Habacker]

Am 17.05.20 um 06:05 schrieb Prasun Kumar:
>     A Qt/KDE-based api is available for this store to access data from this
>     store (see https://api.kde.org/frameworks/knewstuff/html/index.html),
>     which is probably not ideal for non KDE applications like aqbanking or
>     GnuCash. Qt is already used by aqbanking, but KDE libraries are not and
>     GnuCash uses gnome libraries.
> 
>     KDE applications could also include updates via knewstuff (if there
>     is a
>     way to script the store to update the data, which is currently not
>     possible).
> 
> 
> I could not understand the need for these services in this project. 
The above mentioned comments aim at the statements of Martin Preuss and 
Ingo Klöckers and contain basic information on the topic.

 > Sorry if this is a silly question but would the current 
implementation > of fetching datafiles not work with the DB?

it will work.

 > Meaning using the CMake file to fetch the datafile from the bank 
during  the build and using that to update the DB locally?

it works

Martin Preuss suggested to use an online store for updating bank data 
from an installed application and Ingo Klöckers spoke about the 
disadvantage of being directly bound to an online retrieval of data 
without a local copy, which in any case requires an available online 
connection.

In order to meet the above requirements, an additional subtask "Update 
of online banking data by an application" would have to be added, 
building on the planned implementation.

This subtask consists of the creation of an API that allows applications 
to detect and download the availability of updated banking data and an 
extension of the CMake build system to upload generated bank files to an 
online store.

All these things would basically be available with the KDE shop for the 
already mentioned financial applications, if the KDE shop did not have 
the described limitations (only available for QT/KDE, although 
ktoblzcheck currently does not contain a Qt dependency and no automated 
upload is possible)

The better choice is therefore currently the file area of the 
ktoblzcheck project on sf.net, to which the generated files can be 
easily uploaded using scp.

The API for this subtask would still have to be defined, but will 
basically have to include the following methods:
1. initialization - definition of the online store URL and the location 
for the download
2. checking whether updates are available
3. downloading the updates

Furthermore it would have to be clarified which library should be used 
for the download

Regards
  Ralf