Makes sense to me.

Committed, thanks!

Changes have been made in Git for this ticket:

Use longer cachetime for non-changing values Request: 10851 . 
Signed-off-by: Michael J Rubinsky <mrubinsk@horde.org>

  1 files changed, 3 insertions(+), 3 deletions(-)
http://git.horde.org/horde-git/-/commit/7bdf164d596c1bcd3c8c8bed94943bf5b804355c

While fiddling around with the cache time of Service_Weather, I 
noticed that the number of calls to the Weatherunderground provider 
where roughly twice the number I expected based on the cache time. 
After logging the requests, I found before the forecast/conditions are 
updated, a geolookup is performed for the location.

No suprise to find that the returned data is static (probably will 
never change) unlike the forecast/conditions data that changes for 
almost each request. Therefor it might pay to do the geolookup only 
once per session and after that use the looked up station until a 
different location is chosen.

On the otherhand, in organizations where many people are tracking the 
same weather station, it might be more beneficial to just treat the 
cache times for the geolookup and forecast/condition lookups 
differently, setting the first very long. The attached patch will do 
the last. It hardcodes the cache lifetime for the geolookup to 86400 
seconds (one day) and uses the configured 
$conf['weather']['params']['lifetime'] value only for the information 
that is likely to change (and where a configurable lifetime is much 
more useful, to balance the number of requests and the fresh/staleness 
of weather data).

I'm not quite sure if this value should be configurable. The looked up 
data is small (so unlikely will use up lots of cache space) and the 
most one could gain by upping this value to an even higher value is 
one lookup per day. Personally, I don't feel this is worth the effort.