... > > 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.
[Jim] > 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. > > 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. > 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). Thanks. Well, when I'm building an embedded device, I look at the invocations wget that are actually being called in the scripts. Since the end product has no interactive shell, I don't need to have all those extra options enabled! In fact, in wget's case, one can often dispense with the tool entirely- the busybox version suffices. > > ... 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. Well, I guess I'm spoiled by Debian. If it ain't broke, don't fix it. Debian makes man pages because tools should have manpages. IIRC, that was one of the "divorce" issues. > 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. Well, I'd rather have rate-limiting things be optionally compiled than plugged-in, since they'd be useful for embedded devices. [Micah] > >> 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. [Jim] > > I would posit that the vast majority of wget options are used in some > > extremely small percentage of wget invocations. Should they be removed? [Micah] > Such as which ones? > > I don't think we're talking about the same "extremely small percentages". OK, so so far there are three of us, I think, that find it potentially useful. And you have not addressed the use cases I brought up. So I think your "extremely small percentages" assumption may be faulty. > 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. You keep saying that. You seem to think unknown upstream bandwidth is a rare thing. Or that wanting to be nice to other bandwidth users in such a circumstance is a rare thing. I wish I lived in your universe. Mine's a lot more sloppy. > 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. Ah, finally, some meat. You see this as opening a door. Especially as I inquire as too whether anyone has feedback on my implementation, you see it mushrooming into a plethora of options. > And all of this would amount to a very mild improvement over what > already exists. Your universe crisp, mine sloppy (above) ;-) > > 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? Again, again, again, unknown available bandwidth. It can cope, but not automatically. Like I said when I submitted the patch, this essentially automates what I do manually: wget somesite ctrl-c wget -c --limit-rate nnK somesite > > 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? Horse dead. Parts rolling in the freeway. > > 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. I thought my arguments were reasonable. You just never addressed them. You just kept repeating variations on "I just don't see it" > 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 Well, when a guy first joins the list and submits his first patch and gets... But anyway, I think we've finally teased out the basis of your objection, and stop me if I'm wrong, but your bottom line seems to be that you don't seem to think the situation where people don't know how much bandwidth they are sharing with others is common. It would have been good of you to say so earlier. And that you aren't really interested in finding a reasonably good heuristic for this situation but rather are worried about it becoming a monster of options. Anyhow, perhaps I did the wrong thing in bringing it here- perhaps I should have provided it as a wishlist bug in debian and seen how many ordinary people find it useful before taking it to the source... perhaps I should have vetted it or whatever. Tony
