On 10/15/07, Matthias Vill <[EMAIL PROTECTED]> wrote: > Micah Cowan schrieb: > > Matthias Vill wrote: > >> I would appreciate having a --limit-rate N% option. > > > >> So now about those "broken" cases. You could do some "least of both" > >> policy (which would of course still need the time to do measuring and > >> can cut only afterwards). > >> Or otherwise you could use a non-percent value as a minimum. This would > >> be especially useful if you add it to your default options and stumble > >> over some slow server only serving you 5KiB/s, where you most probably > >> don't want to further lower the speed on your side. > > > >> As third approach you would only use the last limiting option. > > > >> Depending on how difficult the implementation is I would vote for the > >> second behavior, although the first or third option might be more > >> intuitive to some of the users not reading the docs. > > > > Third option should be more intuitive to the implementer, too. I vote > > for that, as I really want to avoid putting too much sophistication into > > this. > > I would expect, that you need to variables for holding percent/fixed > values anyway so I was just wondering whether you could do it as I > suggested secondly. > IMHO that should be quite easy to do by a single > if(fixed&&percent)limit=max(a,b) and thus not even result in any > overhead during actual download. > > Greetings > > Matthias > > P.S.: I'm subscribed via news://sunsite.dk, you don't need to CC me.
Thanks for the input, guys. I'll see what I can do. About the parser... I'm thinking I can hack the parser that now handles the K, M, etc. suffixes so it works as it did before but also sees a '%' suffix as valid- that would reduce the amount of code necessary to implement --limit-rate nn%. Any reason not to do so? -- Best Regards. Please keep in touch.
