On 10/11/07, Tony Godshall <[EMAIL PROTECTED]> wrote: > ... > > I have, yes. And yes, it's a very small patch. The issue isn't so much > > about the extra code or code maintenance; it's more about extra > > documentation, and avoiding too much clutter of documentation and lists > > of options/rc-commands. I'm not very picky about adding little > > improvements to Wget; I'm a little pickier about adding new options. > > > > 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. > > Would it be better, then, if I made it --limit-rate nn% instead of > limit-percent nn? > And made the descrip briefer?
Also would it help if the behavior was changed so it "pulsed" occasionally and therefore wouldn't suffer from the initial-measurement-error case. I'm trying to judge whether I should spend more time touching it up into something acceptable or just let it remain a personal hack. > > If the benefits are such that only a > > handful of people will ever use any of them, then they may not have been > > worth the addition, and I'm probably not doing my job properly. ... > > I guess I'd like to see compile-time options so people could make a > tiny version for their embedded system, with most options and all > documentation stripped out, and a huge kitchen-sink all-the-bells > version and complete documentation for the power user version. I > don't think you have to go to a totally new (plug in) architecture or > make the hard choices. > > I know when I put an app into an embedded app, I'd rather not even > have the overhead of the plug-in mechanism, I want it smaller than > that. And when I'm running the gnu version of something I expect it > to have verbose man pages and lots of double-dash options, that's what > tools like less and grep are for. > > Tony > -- Best Regards. Please keep in touch.
