On Wed, Sep 23, 2009 at 05:32:16PM +0300, Eugene V. Lyubimkin wrote: > > Hmm. Good point. Wouldn't it make sense to take the HTTP Response Code > > into account, then? > HTTP is not only source. It can be FTP, or file://, or maybe someone will > write pet p2p download module for cupt. Too much guessings...
Right, didn't consider this. As you speak from modules. Does that mean that cupt uses plugins/modules for each protocol? If so, it would probably make sense to define an abstraction layer for error messages. So that the FTP protocol handler can still say: "Hey, I haven't found the file, but everything else is ok". Depending on weither you get "File not found" or "Some other error" you could then decide with the metric I've described. > > Something like: > > - File not found (404), but de_DE found => No warning > > - Access forbidden (403) or any other response code, but de can be > > downloaded => Warning > > > > So, if you still insist you want this get fixed nevertheless, I will convert a > bug to wishlist then. Well, I don't insist on anything, but I think it would improve your software. I somehow learned that a lot of useless warnings reduce the usefulness of *every* warning, because over time people get trained to ignore warnings at all. Regards, Patrick -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
