-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Jim Wright wrote: > On Thu, 11 Oct 2007, Micah Cowan wrote: > >> It's not really about this option, it's about a class of options. I'm in >> the unenviable position of having to determine whether small patches >> that add options are sufficiently useful to justify the addition of the >> option. Adding one new option/rc command is not a problem. But when, >> over time, fifty people suggest little patches that offer options with >> small benefits, we've suddenly got fifty new options cluttering up the >> documentation and --help output. > > I would posit that the vast majority of wget options are used in some > extremely small percentage of wget invocations. Should they be removed?
Such as which ones? I don't think we're talking about the same "extremely small percentages". Looking through the options listed with --help, I can find very few options that I've never used or would not consider vital in some situations I (or someone else) might encounter. This doesn't look to me like a vital function, one that a large number of users will find mildly useful, or one that a mild number of users will find extremely useful. This looks like one that a mild number of users will find mildly useful. Only slightly more useful, in fact, than what is already done. It's also one of those "fuzzy" features that addresses a scenario that has no "right" solution (JavaScript support is in that domain). These sorts of features tend to invite a gang of friends to help get a little bit closer to the unreachable target. For instance, if we include this option, then the same users will find another option to control the period of time spent "full-bore" just as useful. A "pulse" feature might be useful, but then you'll probably want an option to control the spacing between those, too. And someone else may wish to introduce an option that saves bandwidth information persistently, and uses this to make a good estimate from the beginning. And all of this would amount to a very mild improvement over what already exists. > In my view, wget is a useful and flexible tool largely because there > are a lot of options. The internet is a messy place, and wget can cope. Sure. But what does --limit-percent allow wget to cope with that it cannot currently? > I have a handful of options I've added to wget which are mandatory for > my use. Mostly dealing with timeouts and retries. Useful features which > would not commonly be used. But they mainly fall into the category of features that a large number of users will use occasionally, and a small number of users will find indispensable much of the time. Will you find this feature indispensable, or can you pretty much use --limit-rate with a reasonable value to do the same thing? > Am I correct in reading in to this discussion > that submitting new features is not encouraged? To be honest, I'm shocked to get this sort of reaction over what is, as far as I can tell, an extremely small improvement. If you really care that much about it, I really don't mind putting it in. But if it's really that useful to you, then I don't think your previous comments really conveyed the degree to which that was the case. I repeatedly asked for people to sell it for me, and got very little actual case-making other than impressions that it was a very minor convenience improvement. If it's more than a very minor improvement to you, then I wish you'd have made that clearer from the start. If, on the other hand, it is really, just a pretty minor improvement that happens to be mildly useful to you, could we please drop using this as a platform to predict what my future reactions to new features in general are likely to be? :p - -- 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 iD8DBQFHDwIc7M8hyUobTrERCDJRAJ91SkMNlTc0ssUpejnyEuGp7MqvIwCgir9U 9t7oOJ8y40VerzlnhysFSXw= =u5oK -----END PGP SIGNATURE-----
