-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Tony Godshall 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?
The thought occurred to me; but then it's no longer such a small patch, and we've just introduced a new argument parser function, so we still get to "is it justified?". > And made the descrip briefer? It's not really the length of the description that I'm concerned about, it's just the "number of little options". >> 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. Well, we need the plugin architecture anyway. There are some planned features (JavaScript and MetaLink support being the main ones) that have no business in Wget proper, as far as I'm concerned, but are inarguably useful. You have a good point regarding customized compilation, though I think that most of the current features in Wget belong as core features. There are some small exceptions (egd sockets). > 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. Well... many GNU tools actually lack "verbose man pages", particularly since "info" is the preferred documentation system for GNU software. Despite the fact that many important GNU utilities are very feature-packed, they also tend not to have options that are only useful to a relatively small number of people--particularly when equivalent effects are possible with preexisting options. As to the overhead of the plugin mechanism, you're right, and I may well decide to make that optionally compiled. - -- 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 iD8DBQFHDs2U7M8hyUobTrERCOYoAJ9bIfGbztes0MEfKxAPwpQY/bjJAQCeOAXn 8M6Kj1vLploBN+qENpF2gu8= =K9Sb -----END PGP SIGNATURE-----
