On 10/13/07, Micah Cowan <[EMAIL PROTECTED]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > > > On 10/13/07, Tony Godshall <[EMAIL PROTECTED]> wrote: > >> OK, so let's go back to basics for a moment. > >> > >> wget's default behavior is to use all available bandwidth. > >> > >> Is this the right thing to do? > >> > >> Or is it better to back off a little after a bit? > > Heh. Well, some people are saying that Wget should support "accelerated > downloads"; several connections to download a single resource, which can > sometimes give a speed increase at the expense of nice-ness. > > So you could say we're at a happy medium between those options! :) > > Actually, Wget probably will get support for multiple simultaneous > connections; but number of connections to one host will be limited to a > max of two. > > It's impossible for Wget to know how much is appropriate to back off, > and in most situations I can think of, backing off isn't appropriate. > > In general, though, I agree that Wget's policy should be "nice by default".
Yeah, thanks, that's what I was trying to get at. Wget should be aggressive iff you tell it to be, and otherwise should be nice. In the presense of bad upstream switches I've found that even a --limit-rate of 95% is way more tolerable to others than the default 100% utilization. > Josh Williams wrote: > > That's one of the reasons I believe this > > should be a module instead, because it's more or less a hack to patch > > what the environment should be doing for wget, not vice versa. > > At this point, since it seems to have some demand, I'll probably put it > in for 1.12.x; but I may very well move it to a module when we have > support for that. > > Of course, Tony G indicated that he would prefer it to be > conditionally-compiled, for concerns that the plugin architecture will > add overhead to the wget binary. Wget is such a lightweight app, though, > I'm not thinking that the plugin architecture is going to be very > significant. It would be interesting to see if we can add support for > some modules to be linked in directly, rather than dynamically; however, > it'd still probably have to use the same mechanisms as the normal > modules in order to work. Anyway, I'm sure we'll think about those > things more when the time comes. Good point. I guess someone who wants an ultralightweight wget will use the one in busybox instead of the normal one. > Or you could be proactive and start work on > http://wget.addictivecode.org/FeatureSpecifications/Plugins > (non-existent, but already linked to from FeatureSpecifications). :) Interesting. I'll take a look. > - -- > Micah J. Cowan > Programmer, musician, typesetting enthusiast, gamer... > http://micah.cowan.name/ > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFHESNi7M8hyUobTrERCChSAJ90KmWelT0bH9qQMlArapEdn1ocSACfRHcK > JJmV8QaqcnKTRYam/v0/lwg= > =TPsw > -----END PGP SIGNATURE----- > -- Best Regards. Please keep in touch.
