On Tue, 10 Oct 2000, Georg Horn wrote:

> as the small memory leak in libcurl has been fixed (thanks for the quick
> help!) i made a new version of my perl interface to libcurl. It's
> available from http://koblenz-net.de/~horn/export/Curl.tgz

May I suggest you put a version number in the file name? ;-) It'll make it
easier to track new versions.

Got any massive floods of feedback yet?

> Registering callback-functions and passing lists for options HTTPHEADER
> and HTTPPOST still does not work

You could probably add some functions that allow such stuff to get added,
that return some kind of handle to the list and then you pass that handle on
later.

> I also added a function curl_easy_getinfo() that for now always returns
> the number of bytes that have been downloaded (that's, for now, the only
> thing io need to know after a download...). Later, libcurl shall provide
> this function. (I implemented this by internally using a write-callback
> that counts the bytes.)

If you get a 7.4 pre-release you'll see how libcurl will offer that
functionality in the upcoming release.

> It would be nice to have a function curl_easy_open() that returns a
> filedescriptor or a FILE * pointer, where one can read from for
> downloading or write to for uploading.

I agree.

I'll try to briefly explain why you can't at the moment: nobody wanted it
that bad. I've done a fair share of thinking on how to design an interface
like that, and there's parts of that already implemented and some parts are
documented in suggestions on the curl web site.

I won't stress that work until I get feedback on it and someone that actually
needs/wants it.

There are several benefits with a design like that, but there are several
drawbacks as well. Curl will not be able to have all these nifty features in
the low-level interface. Things that the easy-functions do automatically
(like following Location:) would have to be done by the users of the
low-level interface.

> With the current libcurl, you can only write to stdout or to a file

No. You can do whatever you please with it. You can write it to a file, sure,
but you could just as well copy it to a buffer, add it to a linked list of
your choice or whatever.

> i want to read from a descriptor and immediately process the read data

The only difference here is that you'll get called instead of simply read out
the data yourself. You can very well process the data as soon as you get it.

> or generate the data from scratch and directly write it to some
> filedescriptor to upload it somewhere.

libcurl hides an awful lot of protocol fluff with this kind of interface.
That's why I decided to name it the "easy" interface. It is very easily used
by other applications. It is not the most powerful interface and nor is it as
low-level as I'd like the low-level interface to be.

I welcome all help and feedback I get on my low-level interface design and
implementation.

> Currently i have to write to a file, then reopen that file and process
> the data. Or i have to do "complicated" fiddling with
> callback-functions...

In what way does a callback make this particular implementation more
complicated?

You want a URL. You'll get the data in X pieces. You can either

- loop until all pieces have arrived and for each lap you perform an
  operation.

- get called-back X times and for each time, perform an operation

> Or can this be done with the lowlevel libcurl functions?

Yhey would allow that, yes. Although they're not fully implemented or
designed. Using the lowlevel interface would also make some features
do-it-yourself.

> I also dont like the way errormessages are stored in a buffer that must
> be supplied by the calling program. I would prefer that the curl_easy_*()
> functions either return an errorcode or set some global variable, and
> that an errormessage could be retrieved via a functioncall. Compare the
> errno concept of C.

In one word: "multi-threading". The errno is already in trouble for threads.
Globals are impossible.

Thanks for your work and your comments. I really appriciate ideas and
constructive criticism. I'm dependent on feedback.

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