Daniel Stenberg wrote:
>
> > Georg added an internal (C/XS) version of the 'body callback', which just
> > collects the body in a string, like your sample. I don't know the details
> > of using it, but its described in the XS source (and I hope the pod
> > file).
>
> I don't really see the point in having one "built-in". I'd rather see the
> normal stdout default and then offer/use the callback like this, in perl.

Me neither really. The 'wrapper' should have a callback available at the
perl layer, which can be turned on simply...

> > I actually proposed making the interface more perlish, and supporting OO
> > access around 1.1.2/3 in a quick wishlist discussion we had, but Georg
> > preferred keeping the interface as 'C' like as possible.
>
> Wasn't that more an argument to where the OO'ish stuff would be implemented?
> If I understood things correctly, Georg argued against making the XS
> interface OO. Instead we should make a layer on top of this lowest crude
> layer. That would offer the biggest flexibility and it would match the
> approach used in PHP and other languages. I'm in favour of a such approach.

Actually, blessing the struct curl as the perl object would probably be
just fine. The layering can be more conceptual than actual - a 'new
Curl::easy' could give you an object which can then be operated on by
complex methods (functions) which do a lot of things for you, or by low
level (curl_easy::setopt etc.) methods. The methods can be both C (in
the .xs file) and perl (in the .pm file).

(Aside, the Curl::easy object really needs to be a (blessed) struct
around the current curl struct though, to deal with perl specific locals
like the extra callback pointers etc. that aren't libcurls problem...)

> > Looking at this is certainly on my list for when I get a 'round tuit'...
>
> I'm not a diciplined perl hacker, but I might have a go at this one of these
> days unless anyone else gets there first.

Prepare to loose hair (assuming you have any) if you dig into XS...

Cris
Received on 2001-09-18