GSoC project discussions

[Prasun Kumar]

>
> The above mentioned comments aim at the statements of Martin Preuss and
> Ingo Klöckers and contain basic information on the topic.
>

Ok. I understand now.

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.
>

Ok. I will add it to my project proposal. I am thinking of doing this
before the first evaluation. I will adjust the timeline accordingly.

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
>

cURLpp looks like a good choice. It is the official C++ binding for
libcurl. Any other suggestions?

I am thinking about how to approach the update checking part. cURLpp can
download the file given a URL but I didn't find any inbuilt API for
fetching the contents of a URL (directory) yet.
I will keep looking.


Sorry for the delay in reply. I was unavailable due to health reasons.

Thanks,
Prasun

On Mon, 18 May 2020 at 14:45, Ralf Habacker <ralf.habacker at freenet.de>
wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-finance-apps/attachments/20200523/e77e8a46/attachment.htm>