ANNOUNCE: xfce4-weather-plugin 0.8.0 released

[Harald Judt]

Am 27.07.2012 10:28, schrieb Liviu Andronic:
> On Fri, Jul 27, 2012 at 9:28 AM, Harald Judt <h.judt at gmx.at> wrote:
>> Am 26.07.2012 20:38, schrieb Liviu Andronic:
>>> https://code.google.com/p/weather-notification-android/issues/detail?id=72
>>>
>>
>> Since weather-notification-android uses it, I wonder why not use google's
>> API? It's undocumented and unofficial, but looking at example data it seems
>> very simple and you won't need any documentation to understand it, and no
>> license (I think, but did not verify). The diversity of data it provides
>> doesn't match that of met.no, and some values like wind may need more effort
>> to parse, yet it could probably be used to replace the "current conditions"
>> we have now.
>>
>> Does anyone have experience with it? Why does the author of
>> weather-notification-android want to switch from it to another provider?
>>
> Likely because users are unhappy with Google being systematically
> notified of their IP address, but I could ask. In any case, the same
> issue would arise for the Xfce plugin: People might not be happy with
> the data flowing from Mountain View.

Personally, I wouldn't care about that. What else do they get except 
your IP and information about how often you've downloaded weather data? 
So maybe they know when you're online and that you're interested in 
weather conditions (who isn't?). Yes, they might combine that data with 
other they have if you're using other of their services. But there will 
be no ads shown, no cookies saved, and you don't have to pay for it. 
You're just downloading an XML page regularly. Any other provider you 
use will gain that kind of information too.

> If we are seriously considering Google as a provider, then I would
> suggest to give serious consideration to DDG, a privacy-respectful
> search engine that incidentally is the default search engine of
> Midori. Searching for 'weather oslo' in DDG [1] will essentially
> provide the same info as Google (not to mention that it systematically
> provides both types of units: C/kph and F/mph). And I've just sent
> them an inquiry regarding the existence of a free, public API and its
> potential use by our plugin. Will keep you posted.
> [1] ddg.gg

A public API would be fine indeed, but a search results page is no good 
solution, a small change can break the plugin easily. I wonder whether 
they are allowed to make it public though. As for unit systems, that is 
not really of interest, one can look up formulas and do a bit of math. 
We already do.

>> Otherwise, I can only think of making the providers interface pluggable, and
>> someone has to write plugins for the plugin, accessing data from a local
>> weather data provider perhaps. Seems quite a hassle for such a simple
>> plugin, though. And then there's still the problem of APIs requiring
>> subscriptions and licenses.
>>
> That would likely be much overhead for little value. I think we should
> find one usable provider (or two) and stick with it.

If we can't find a suitable provider that does it all, I see no way 
around it. libgweather decided to go this way, and I'm quite sure their 
devs spent some time searching for good services too. I wonder how good 
their library works for locations in Europe (UK excluded), Africa and Asia.

Harald

-- 
`Experience is the best teacher.'