Daniel Stenberg wrote:
> 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
> [ ... ]
> The modified code looks relly good. Perhaps you should consider adding
> support for the READFUNCTION and WRITEFUNCTION too while you're at it.

I'm having trouble figuring out how to pass filehandles from C to Perl.
I wrote to Georg Horn and he is also not sure how to do this. I'll continue
to research this, but it's non-trivial.

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

OK, I'll take a look ... once I figure out how to make the read and write
callbacks work.

If someone else wants to start writing the OO part, it's reasonable to assume
that you'll have read and write callbacks to work with soon, that will function
much the same way as the progress callback.

> > 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?

Oh, duh. I didn't think about threading. But we can't just have a void * passed
to perl. I can make it an SV *, which is a perl scalar value -- that should be
generic enough.

> > 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.

Would it make sense to modify the C code to behave this way, and have an option
like CURLOPT_PROGRESSFUNCTION_ENABLEABORT, which must be set to a true value to
give the progress function this ability? It might force some current libcurl
users to add one line of code, but it would make things consistent between C and
Perl.

> [ ... ]
> > 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.

Can the FILE * be NULL? If I can't solve this file pointer debacle, I
could at
least provide a callback that doesn't use it. It wouldn't be necessary in
order
to write the output into a variable.

> Anyway, this looks like a really good start!

:-)

_______________________________________________
Curl-library mailing list
Curl-library_at_lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/curl-library
Received on 2001-04-03