On Sun, 1 Apr 2001, Forrest Cahoon wrote:

> I've made some mods to Curl::easy so that you can now write a progress
> function in perl. The code is available for now at
> http://www.pconline.com/~forrest/Curl_easy_progress.tar.gz
>
> I made some cosmetic changes to the code which I hope don't offend Georg
> Horn: basically I changed Curl::easy::curl_easy_init() into
> Curl::easy::init() and so on. I don't want to fight over details like
> that, but it looked better to me that way.

The modified code looks relly good. Perhaps you should consider adding
support for the READFUNCTION and WRITEFUNCTION too while you're at it.

> After looking at the code some more, I came to the conclusion that Sander
> van Zoest is correct in suggesting that the OOifying is best done in
> perl, and that the XS code should be as simple as possible a wrapper
> around the C functions (something Georg Horn has done an excellent job at
> ... getting these callbacks to work is just the last little bit).

... which incidently is the same decition the PHP guys seem to have made for
their OO interface to libcurl.

There might be inspiration to find in the LWP interface as shown before, but
also in the PHP's Net_curl OO interface.

> The perl progress callback expects 4 values, not 5. I decided not to
> pass the initial void *clientp, because there's no telling what it is,
> and any persistent data needed can be kept around in the perl world.

Can it? What if you fork and decide to fetch two files at the same time. Then
you'll get the progress function called for both files intermixed, without
ever being able to tell which callback is connected to which transfer. Or am
I wrong?

> I also decided that a perl "TRUE" value returned from the progress
> function was an "everything is OK" value, and a perl "FALSE" value would
> cause a CURLE_ABORTED_BY_CALLBACK, because that seemed more in keeping
> with perl idiom. (It's still disturbingly easy to return a FALSE value
> by mistake, because if you forget to specify a return value, it's just
> value returned by the last thing you called. It might be better to not
> allow the callback to cause the transfer to abort at all.)

You might consider adding a separate call for aborting the transfer, and that
would set some variable in XS code that would cause the C-code to return a
value that causes libcurl to abort the operation.

It would make it less likely that anyone would abort a transfer by mistake
simply by (not) returning the wrong value.

> To see how to use the callback, look at the test.pl file; I've
> implemented one there.

Seems easy enough!

> I have more studying to do before I can get the input/output callbacks
> working. I may not understand these, but at the moment I'm thinking the
> output callback is the key to writing data into a perl variable instead
> of to a file.

It certainly is, yes. The write callback will be called each time libcurl has
data to write to the destination, be it a file, a variable or stdout.

Anyway, this looks like a really good start!

-- 
  Daniel Stenberg -- curl project maintainer -- http://curl.haxx.se/
_______________________________________________
Curl-library mailing list
Curl-library_at_lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/curl-library