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