DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG� RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=32949>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND� INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=32949 [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX ------- Additional Comments From [EMAIL PROTECTED] 2005-01-05 23:10 ------- As you observed, there already is a default timeout. By default, network I/O blocks within the default parameters of the underlying OS. The individual programmer using the library knows best what timeout is suitable for his/her application and should set it as appropriate. You are the first to request a different approach. Until there is evidence that a majority of users prefer a different approach, I'm marking this request as won't fix. I understand your desire, but I disagree with your reasoning. A default timeout other than the OS default that you feel is appropriate will not be appropriate for someone else. Therefore the need to set the timeout explicitly will not be minimized, and I'd argue it would increase because common practice is to rely on the OS default in the face of unreliable networks (e.g., you don't want a 2 GB file transfer to die just because there is a 10 minute loss of connectivity; and if you do, you can reset the timeout based on your needs). Regardless, if you want a different default, you can subclass FTPClient and set the timeout in the constructor. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
