On Tue, 19 Dec 2000, Georg Horn wrote:

> But speaking seriously, the perl interface i wrote was just a hack, as i
> needed it badly (calling curl as an external program was too
> inefficient). I've been a C programmer for years, and have never liked
> object oriented programming, so my perl interface is not very "perlish"
> or object oriented, but just imitates the C interface.

I too write perl programs in a very C-like manner so I know exactly what
you're talking about! :-)

> Everyone may feel free to improve it...

I think just discussing how it could look like is a good start. To see if
anyone cares or have any bright ideas.

Personally, I would certainly enjoy a comfortable interface.

> > /* get web page */
> > @body = $url->get('http://curl.haxx.se/');
> >
> > /* print the page */
> > print @body;
>
> That's really the "perlish" way to fetch a page. ;-) What about
> ($errcode, @headers, @body) = $url->get();

Hm, not bad, that's truely a perlish approach. Otherwise, one could consider
this style:

 @body = $url->get();
 @headers = $url->headers();
 $errocode = $url->error;

> BTW: The current way in libcurl to specify a buffer where error messages
> may be stored is not very elegant, imho. I think retrieving the error
> message with the newly introduced function curl_easy_getinfo() would be
> more consistent.

Yes it might be. The reason I introduced that buffer thing was to not use
more memory than necessary in cases where the client program doesn't care
about the error message. To let curl_easy_getinfo() return the error message,
it has to be allocated and stored always.

> But how to put the headers and the body into the arrays. The current perl
> interface is still missing the feature of registering callback functions,
> and i haven't had the time to implement this. We could make an internal
> callback function within the perl interface, that collects all header and
> body lines in two large buffers and makes these buffers available to the
> calling script? This may further increase performance, as we don't need
> to save the results to a file and then open and read this file...

I imagined something like that. I don't think perl coders would like to care
about callbacks or anything. If a perl code retrieves a very large file, it
is likely that they'll want it straight into a file. If it is a little
smaller, straight into an array.

> That makes me curious too. Anyone out there has ever used the perl
> interface?

I have this bad habit of running weird development versions of curl and
libcurl in various setups, which prevented me from installing the perl
interface when you shipped it. Since then, the complexity when using the
interface has kept me from it.

I want this to change, I'd like all my URL-fiddling scripts in the future to
use the perlish interface to curl!

-- 
  Daniel Stenberg -- curl project maintainer -- http://curl.haxx.se/