Cris Bailiff <c.bailiff_at_awayweb.com> wrote:
> I figured it would be neater (see earlier postings) to have the wrapper hide the
> extra stuff, and just work off what you pass in - if you call CURLOPT_FILE with a
> filehandle, the behaviour is as normal, if you call it with an SV* which is a sub
> reference, you get a callback to that sub (per chunk), and finally if you pass
> either a plain scalar or a reference to a scalar (undecided yet), an internal
> callback could fill that scalar for you... (maybe).

Maybe it's just me, but the one thing that troubles me about this
(otherwise very good) approach is that it changes the meaning of
CURLOPT_FILE from what it means in the C code.

I'd rather see another "namespace" for perl-specific options, although
I'll admit that anything I can think of is clunky (e.g 'CURLPERLOPT_').
Still, I think it will help keep things straight for people who may in
the future work with the low-level perl hooks: they won't have to puzzle
over the XS code to figure out which options are the same as the C
library and which ones are different.

My approach was going to be simpler: instead of putting any smarts in
the XS code, I was going to make CURLOPT_FILE just set an SV * which
would be passed to a perl write function set with CURLOPT_WRITEFUNCTION,
using a simple wrapper like I did for CURLOPT_PROGRESSFUNCTION. (If
CURLOPT_WRITEFUNCTION isn't set, a default function that expects a
filehandle is invoked, giving the same behavior as in C).

The idea I had was that everything that was even modestly complex could
be done in another layer of perl wrapper -- the distinguishing between
callback, scalar, and filehandle you describe could be done there,
instead of in XS code.

Of course, the performance of XS code is better than perl, so it may
make sense to do some more complicated stuff in XS. That's a tradeoff.

Forrest
not speaking for merrill corporation

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