On Wed, Sep 17, 2014 at 11:11 AM, Frederic Peters <[email protected]> wrote:
> Andrea Veri via RT wrote: > > > > I'll update the bug report with the RT ticket number once I get it. > > > > Can you provide me the correct URLs (as found in the gnome-weather app) > we should reverse proxy requests from? > > > > Ideally we can add a weather.gnome.org subdomain and have that reverse > proxying to the two available providers through mod_proxy. That will > require gnome-weather to adopt weather.gnome.org as its main provider but > that shouldn't be hard ;) > > I was just playing the middleman, I added Giovanni to the CC list, he > will be able to correct me if I'm wrong. > > I looked at the various libgweather sources, here are the base URL > that are used in them: > - iwin: > http://www.weather.gov/forecasts/xml/sample_products/browser_interface/ndfdBrowserClientByDay.php > - metar: http://weather.noaa.gov/cgi-bin/mgetmetar.pl > - owm: http://api.openweathermap.org/data/2.5/forecast > - wx: http://image.weather.com/web/radar/ > - yahoo: http://weather.yahooapis.com/forecastrss > - yr.no: http://yr.no/place/ and > http://api.yr.no/weatherapi/locationforecast/ > > Is that ok? > I won't comment on whether it makes sense or not to setup the TLS server at all, because I share some of Andrea's concern. In any case, it should be noted that: 1) code for wx exists, but wx is about screen-scraping a radar image off weather.com, which is probably against their terms of service, so while library code exists, no application code makes use of it and the library support should be probably removed - in any case, we don't want a GNOME Foundation server continuously scraping weather.com without authorization 2) yr.no old style (yr.no/place) is only used in the unlikely case that a location is missing geographical coordinates, which is impossible unless the database is modified manually or the application forces it through 2) yahoo has proper TLS support, so it's just a matter of enabling it in the library, but... 3) yahoo and owm are opt-in by the application using libgweather, and a library that does not override the default set of backends will only use metar, iwin and yr.no (new style api.yr.no), but... 4) gnome-weather overrides the default to disable iwin (because it provides unsufficient data) and reenables owm (unless overridden by a debug environment variable), but... 5) if both yr.no and owm are available, either yr.no will work, or neither will, so yr.no is tried first and owm ignored, which in practice means... The only backends that matter are yr.no new style api.yr.no and metar. Everything else is not tried by gnome-weather and exists for legacy reasons or fringe use cases that opt-in by the application. Cheers, Giovanni
_______________________________________________ gnome-infrastructure mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gnome-infrastructure
