[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: KDE review for KWeatherCore
From:       Nicolas Fella <nicolas.fella () gmx ! de>
Date:       2020-12-21 14:45:22
Message-ID: b8665dcf-66b7-aed5-be26-4f46e1a5f05b () gmx ! de
[Download RAW message or body]


On 12/21/20 3:19 PM, Friedrich W. H. Kossebau wrote:
> Am Montag, 21. Dezember 2020, 07:16:09 CET schrieb hanyoung:
>> KWeatherCore: https://invent.kde.org/libraries/kweathercore is a librar=
y 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 t=
he
>> 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 mailin=
g
>> 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 upo=
n 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 implementatio=
n-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 pa=
rt of
> it.

Please keep in mind that having such a daemon would be challenging to
impossible to implement on Android and possibly other platforms as well.

Let's not overengineer the wheel without having to and focus on use
cases relevant for our current apps and less on hypothetical use cases.

Cheers

Nico

[prev in list] [next in list] [prev in thread] [next in thread]