Andrew Francis wrote:
>
> "Daniel Stenberg" <daniel_at_haxx.se> wrote:
> >
> > On Fri, 26 Oct 2001, SM wrote:
> >
> > > The rate-limiting feature may be of interest to people using libcurl
> to
> > > build apps which perform downloads in the background.
> >
> > Yes, but we must always ask ourselves if there's a good idea to add
> specific
> > features to the library that is already possible for an application to
> add
> > using the standard interfaces. In this case, I think we should go for
> this
> > latter solution. If the current interface is not good enough for it,
> we
> > should change that situation.
>
> At one point there was discussion of implementing some sort of "filter"
> system, where the data stream was passed through one or more filters
> that obey a certain interface, before being passed to the callback
> function. So for instance you have something like:
>
> +======+ +=============+ +==========+
> | curl | ---> | gzip filter | ----> | callback |
> +======+ +=============+ +==========+

It isn't great because the only way to slow this down is to pause
the entire program (or thread). I prefer to do other work while I'm
waiting for long enough that it makes sense to send data at whatever
speed you want. For simple tools, I like having Curl run the main loop
and making it's use very easy. However, for more advanced tools,
the library cannot control the main loop and should be driver more
explicitly from the outside.....

Ben

>
> I think this would also be an ideal way to implement a speed limiter.
>
> Is the 'filter' idea still on the cards?
>
> (I'm going to have a lot of spare time starting in a few weeks - I'd
> love to try and implement this myself if noone else wants to :)
>
> --
> Andrew Francis
> locust_at_familyhealth.com.au

-- 
Ben Greear <greearb_at_candelatech.com>       <Ben_Greear AT excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear