Hi Raf, > I'm sure that the users of the port had already noticed it a while back > but, as it stands, ansiweather is broken.
Yep, you can be pretty sure it's broken and about to be recurring as it's not such an easily solvable problem below the surface, please read through the next comments. Like others I too spotted it on the day it broke by chance, was not certain it is a port I'd use daily period. Thanks for following this up, looks like an update is pending review: http://marc.info/?l=openbsd-ports&m=144622297712023 > A fix is already in the git repository but requires each user to apply > for an API key. Asking each client to manually apply for an API key would actually render the shell script OWM API presenter as pretty useless complication and drive it away into reseller business category (wait is it not the model already?), just consider how stupid it is to ask visitors to subscribe before reading a piece of data dubbed open on the Internet (that you already have floating around everywhere). Now let's not get into the discussion of page scrape compared to web service API junk food talk, but you get the point. > At the same time, the author is pondering applying for > an app/project-wide API key. While pondering, the API could change, then after a while start asking monetary tokens, or simply rate limit because it can't take up any load (at least not just for free without adds and touch ups of data points at which point our discussion is a waste of time if not already). Temp fix now the key for app developers, until bait and switch clicks through (ticking already). Can't compete with the GOOGs at this libre pace, right (well they are not free too in any meaning of the word)? Oh wait, every mobile device has environmental sensors, and so do wagons on the road, yet 'nobody' thought of portable weather stations and NTPd like clients. This taxable app approach makes me sick. I like the port goals though, presenting valuable weather data, except the data serialisation method is junk and everything nasty about the provider dependency decay designed into it. > Also, IMVHO, 'astro' doesn't seem like a good fit for the port - i.e. in > FreeBSD ports and NetBSD pkgsrc it is under 'misc'. Worse choice would be a misc category to clog, no? Thanks for actually proposing category placement for this port, yet there are no candidates for environmental readings to make it a category so why not astro? Too much info than bargained for.. just scream in a private mail (been having a thought about it for a while you see). Thanks for pointing out the problem zones, and let's see how this fares. Predictions are hard when you don't have a horse in the race. Regards, Ant
