On Wednesday, July 30, 2003, at 02:06 AM, Daniel Stenberg wrote:

> On Tue, 29 Jul 2003, Daniel Noguerol wrote:
>
>> I'm attaching my quick FTP REST change as a diff against 7.10.6.1 at
>> the end
>> of the message.
>
> Applied and committed to CVS just now.
>

Thanks!

>> I like the new curl_easy_cookie addition that is being worked on. The
>> SENDFUNC is very similar to what I have done, only I return the actual
>> cookie string rather than a linked list. Has there been enough
>> agreement on
>> this new API that implementation can start? I would be willing to
>> assist on
>> this, although I would appreciate code sanity checks since my
>> straight C
>> coding isn't anything to brag about :P
>
> I think we have enough agreement to be able to start this, as I trust
> that
> once we get something basic working we'll get more feedback and
> thoughts from
> people that try it, and we can adjust the implementation then
> depending on
> what we find out.
>
> I will of course appricate help on this, as I suspect that won't be
> able to
> lead any work on this topic for a while (see my "20003 plans" here:
> http://curl.haxx.se/mail/lib-2003-06/0127.html). Sure, if you can
> provide
> patches I'll step forward and check/review the code.
>

Okay, I'll start looking into doing it :)

> I'm also in the middle of a pretty serious attempt at introducing
> asynch name
> resolves to libcurl using ares, which involves some hefty changes all
> over the
> libcurl code. I hope I manage to get it working during this or next
> week, and
> then commit it. It'll be controlled by a preprocessor check for now
> and I'll
> do my very best to make sure that everything works "like before" with
> the
> asynch stuff disabled. I'll be back with more details on this topic in
> a
> separate mail later.
>

This sounds very cool.

>> As for a speed throttle, I assume the easiest way is to sleep in the
>> progress callback for the appropriate amount of time to keep the
>> transfer
>> rate at the configured speed?
>
> The curl tool does the sleeping in the read and write callbacks, as
> they are
> the ones that are called when data is actually transfered.
>
>> Would this be preferable in libcurl itself or just keep it
>> client-side?
>
> I think I rather keep this client-side.
>

I have tried both approaches (callback and in the library itself) and
the problem I see with sleeping in the read/write callbacks is that if
you look at bandwidth utilization, you see some nasty spikes... full
bandwidth for a brief moment, than nothing, full bandwidth, nothing,
etc. If you actually do the speed check at the time of reading and only
read the appropriate number of bytes from the socket, you get a nice,
smooth bandwidth graph. For my purposes, I am going to put it into
libCURL itself and add a parameter to set the upper bandwidth limit. If
you want to keep it client side as far as the main branch goes, I
understand :)

> --
> Daniel Stenberg -- curl: been grokking URLs since 1998
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/
> direct;at.aspnet_072303_01/01
>
>

-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
Received on 2003-08-02