> The way I see it, whenever ID is given, the program should ignore > the City and St tags from the default section of the configuration > file if there's no forecast for that location. Current behaviour > is quite confusing, having weather conditions and forecast for > different places - it doesn't make much sense. [...]
Thanks for the suggestion! I agree, the default handling is
confusing and I have a work-in-progress sitting in my $HOME which
will hopefully rectify the situation, with dummy default values that
make it obvious what is happening, and better logic around implied
options. I'll see if I can't bang out the rest of what I need for
1.4 in the next weekend or two.
Part of the issue is a design problem stemming from my original
choice to mix data and configuration information into one place.
This is going to be rectified in the 2.0 release, along with the
ability to specify additional data sources and (hopefully) a
companion utility/invocation added to triangulate the closest
stations and forecaset cities based on coordinate data. Support for
additional input formats and possibly even a flexible data
translation specification for them are also on my roadmap for 2.0,
but may get pushed off until 3.0 depending on what's involved.
I'm also planning to work in proxy support soon (in the upcoming 1.4
maintenance release), since that was a major omission in my opinion.
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
signature.asc
Description: Digital signature
