-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Tony Godshall wrote: > [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.
(You've misattributed this: it's me talking here, not Jim.) > OK, so so far there are three of us, I think, that find it potentially > useful. One of whom, you'll note, was happy to see it as a module, which is what I had also been suggesting. >> 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 do not think it's a particularly rare thing. I think it's a fairly easily-dealt-with thing. > 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 What I've been trying to establish, is whether automating such a thing (directly within Wget), is a useful-enough thing to justify the patch. >> 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. Is it? I was talking to Jim, not you. He actually hadn't said very much until this point. >> 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... Gets what? One should not expect that all patches are automatically accepted. Jim knows this, and has also seen other people come with patches I've accepted, which is why it's just silly to accuse me of something there's already ample proof I don't. And what is it you "got"? Did I ever say, "no, it's not going in?" Did I ever say "I'm against it?" What I repeatedly said was, "I need convincing." > 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. Sure, vetting it is entirely helpful. Getting feedback from a larger community of users is very helpful. And, lamentably, the current activity level of this list is not sufficient that I can gauge how useful a feature is to the community as a whole from the five-or-so people that participate on this list. I cannot gauge how useful a feature is from how loudly the contributor proclaims it's useful. I already _know_ you find it useful, as you cared enough to bother writing a patch. What I was hoping to hear, but hadn't heard much of until just now, was more support from the rest of the community. Jim had spoken up, but not particularly strongly. Rather than waiting for people to have the chance to speak up, though, you just got louder. What is most interesting to me, is your reaction to my statements, which were never "I'm not putting it in", but "I think it should wait and live as an accessory." And to this you get upset, and both defensive and offensive. This does not make it likelier for me to include your changes. In this specific case, there's probably a good chance it'll go in (not for 1.11 though), as I'm clearer now on exactly how useful Jim finds it, and we've also had another speak up. In the future, though, if you've got something you'd like me to consider including, you might consider just a bit more patience than you've exhibited this time around. Hopefully this thread can go away now, unless someone has something truly new to contribute. - -- 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 iD8DBQFHD/mZ7M8hyUobTrERCLCrAJ9wApBrS12uqTJ/5pNDLxNI9zbJkACgkdBr gCwWMhPZ/kzzY1ynR8aof+g= =t9s1 -----END PGP SIGNATURE-----
