On Tue, 3 Apr 2001, Forrest Cahoon wrote:

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

You don't have to pass file handles. The first argument in the write and read
callbacks are generic pointers. They're 'FILE *' just because they "emulate"
fwrite() and fread(). You can pass any pointer.

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

That's probably good enough, yes.

> > 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.
>
> 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 think C and perl differs in many ways, but they definetely are in different
levels. For C callbacks, there's nothing odd with requiring strict arguments
and careful checks of what's returned etc. For Perl programs, I think the
situation is a bit different. Perl programs are meant to be fast to write and
should better survive more sloppy practices.

I don't think most people that use the Perl interface will have experience
from the C interface, why exact consistency may not be of the utmost
importance.

Many developers have used the PHP interface to libcurl, which is basically a
1-to-1 mapping against the C interface, however not identical. Most of those
guys have no clue of how the C interface looks like, and they (quite
rightfully) probably don't care! ;-)

I am very resistant against forcing current libcurl users to modify their
code.

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

The FILE * is solely at your callback's interest and the application that
sets the pointer. If you want to pass a NULL to the callback, then pass a
NULL. If you wanna pass a void pointer to a JPEG of your grandmother, pass
that!

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

But then again, you would have to append the output to a global variable that
would make threading hard if not impossible. Or am I missing something?

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