KDE review for KWeatherCore

[Friedrich W. H. Kossebau]

Am Montag, 21. Dezember 2020, 07:16:09 CET schrieb hanyoung:
> KWeatherCore: https://invent.kde.org/libraries/kweathercore is a library for
> querying weather forecast data. During the development of KWeather, we
> found the need to have a weather library. KWeatherCore is the result of
> extracting weather data fetching code from KWeather. I think having a
> dedicated weather library can serve the following propose: - simplify the
> KWeather code
> - easier to develop a weather daemon
> - potentially less code duplication across KDE
> 
> Many of you may have already seen my previous email to kde-devel mailing
> list.
> Thank you for your constructive suggestions. Here are something I want to 
clarify:
> > I would also propose to consider doing a demon instead, so different
> > programs/processes all interested in weather forecast data could share the
> > data
> 
>   The end goal is a daemon indeed, but we want to build the daemon upon the
> library. This would give us flexibility in the future if we don't want a
> daemon. At least KWeather and other projects can still benefit from the
> code.

My idea/proposal there is that the library internally makes use of that demon. 
So code which uses KWeatherCore does not need to know that implementation-wise 
there is a demon (which might also need to be a build-time option, think app 
bundles who do not like separate demon processes).
So the demon would not use KWeatherCore, but be a(n optional) backend part of 
it.

To give you more ideas: I would also envision there could be proxy servers one 
day. Think of big organizations with lots of devices at same location due to 
lots of people in same buildings, so interested in the same local weather 
data, like schools, office-heavy companies, they could have a single proxy 
server and all clients would just use that proxy, saving the weather/
environment service provider some bandwidth, also adding some privacy layer 
onto the provider. If KWeatherCore would be prepared to handle that scenario 
in one way or the other, even better.

> > but we want to make sure we don't end up with two things.
>   I admit there are some overlapped functionalities. But KWeatherCore isn't
> designed as a weather data provider as Weather DataEngine. Instead, it's
> trying to be the building block of weather related applications.

Consider a DataEngine to be some kind of Plasma-specific type of library, as 
in, as shared logic module, just with a normalized API. This technology though 
failed to stay in developers' hearts, and these days is deprecated and instead 
all DataEngines are turned into plain C++ libraries with specific API.
The Plasma weather dataengine from plasma-workspace/dataengines/weather might 
have already been turned into a library similar to kweathercore, just that the 
last maintainer (me) was attracted by other even more interesting stuff and 
no-one had picked up so far. See also https://phabricator.kde.org/T13349

Looking at the current API of KWeatherCore, e.g. 
KWeatherCore::WeatherForecastSource, I think the Plasma Weather DataEngine and 
KWeatherCore are very much overlapping, other than the one being a Plasma 
"library" and the other a normal C++ library.
With KWeatherCore now thankfully being created by yours, the weather data 
related features of the weather dataengine would be ideally merged into 
KWeatherCore, so that the weather dataengine itself can then be deprecated and 
all existing weather DataEngine consumers (like kdeplasma-addons/applets/
weather or some on https://store.kde.org/browse/cat/424) could be ported to 
something based on KWeatherCore (I guess there would be some kind of KWeather 
qml plugin then for these, next to the KWeatherCore library itself).

You will find the normalized data model used by the DataEngine here in the 
class documentation, which then would ideally be merged into the normalized 
data model of KWeatherCore, so the existing applets would not need that much 
porting but get data close to what they are using now:
https://invent.kde.org/plasma/plasma-workspace/-/blob/master/dataengines/
weather/ions/ion.h
(that normalized data model BTW lacks support for sub-day-granularity for 
forecasts (like day & night as available with the Canadian service, resulting 
in bad hack and resulting display in the Plasma applets when using that 
service), so with room for improvements itself)

The weather dataengine also has a plugin mechanism (using DataEngines again 
for some perhaps random reason, just ignore that) to allow adding support for 
further weather data provider services by 3rd-party. Such an extension feature 
would be also nice to have with KWeatherCore. Some more info also here:
https://frinring.wordpress.com/2016/04/02/plasma-weather-widget-code-template-available-to-add-your-favorite-weather-data-provider/

Then as Volker already pointed out in good detail, using non-KDE service 
providers on the internet comes with lots of traps, related to privacy and 
terms of usage of those services, which also happen to change by the time. 
Even more as private companies are seeing business opportunities in that area 
and push to cut down free public tax-payer-funded services (and using those 
just for themselves sometimes, tss). Or international issues, with services in 
one country being restricted or with questionable circumstances for people 
living in another country.
So the code connecting to individual service providers should be well 
encapsulated for overseeing if conditions are met as well as allowing simple 
substitution, if a service is not usable. That should be baked into the design 
of the library from the very start. Similar like we can switch which DNS 
servers to use/trust or NTP servers or other data services. Just that those 
usually have standardized protocols/data, where with weather data we need to 
do service-specific normalization on our side to map into the data model in 
our library API.

So, some material for inspiration :) I am sure you will find your own way 
here, the start looks good. As much as I would like to help with code given my 
previous weather report code related activities... I already promised myself 
to other adventures, so just can drop some of my notes here.

Cheers
Friedrich