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.

Reply via email to