On Thu, 25 Oct 2001, Ben Greear wrote:

> > > One of the things I want to support is rate-limitation.

> > Well, if you don't want full speed, your custom callbacks can just
> > delay the operation as much as you want.
>
> If it's a feature that other folks would want, it might make sense to add
> it into the library, but I doubt many people will want it...

I've got the suggestion before for the 'curl' command, from people who have
limited bandwidth who don't want their curl downloads to suck up their entire
pipe. I haven't added anything such, and I would say that it would be outside
of the library even then.

> > See also Steve Dekorte's suggested new API for more advanced select()
>
> Well, I'm writing a server...it has at least one management connection
> (descriptor) at then there's whatever is hiding in curl. Normally, I put
> the data fd's and the management fd in the same select loop so that if no
> data is incoming I can still get management data in... If curl has it's
> own loop (and I'm single threaded), then I block my management connection
> on the data connections...

Yes, that's true and that's why we discuss what kind of other arrangements we
should introduce to improve this situaion.

I'm glad you come here being enthusiastic about helping out to improve this!

> I think I'm going to be able to mimic that same behaviour by checking my
> management descriptor on the progress callbacks (or the read/write
> callbacks if necessary)...

Yeah, that could most probably do as a work-around until we get something
better going.

> Another thing we could do is poke FDs and timeout into curl's loop and
> have it give callbacks when one of the external FD's is selected... To
> keep curl's loop spinning freely, can use non-blocking IO. The user can
> specify the maximum select timeout, so the user can be sure that they
> will be called on a regular basis...

Hm, yeah that would of course also be possible. Perhaps the coolest
possibility would be to allow either way, so that programmers could pick the
one that suits them best:

o Version A would be that the application would get the read/write FDs from
  curl and add its own FDs and then do the select() by itself. When one of
  the curl FDs are ready, you just call curl_deal_with_that_fd().

o Version B would provide all the app's read/write FDs to curl and then get
  callbacks when there's any action on them.

Version A would probably offer the highest level of flexibility to the
application author...

> Anyway, the current scheme is good enough to get me started...and perhaps
> I'll see an easier way to do what I want when I understand the library
> better...

Just dive right in. Get the CVS sources or a recent 7.9.1 pre-release, things
have changed somewhat internally since the 7.9 release. (Or wait a few more
days until the 7.9.1 public release comes flying.)

-- 
    Daniel Stenberg -- curl groks URLs -- http://curl.haxx.se/