cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: CURLOPT_STDERR option not customizable

From: Daniel Stenberg <daniel_at_haxx.se>
Date: Wed, 13 Mar 2002 23:41:46 +0100 (MET)

On Wed, 13 Mar 2002, Jean-Philippe Barrette-LaPierre wrote:

> > In order to make a good suggestion, I think it would help if you would
> > describe your use case for this function.

> For the C++ wrapper I want to be able to output this output to a stream so
> I need to pass a basic_stream<T>* instead of a FILE* and the function
> processing need to be different.
>
> I suggest:
> int function( void *data, size_t size, void *stream)

> (in fact I don't why you're putting a CURL *easyhandle in your new function
> prototype, can you elaborate more on this?)

The reason for the CURL handle in the prototype is subtle at this point in
time, but I'll try to elaborate on my thoughts:

The multi interface allows multiple simultaneous transfers. Each single
transfer is done with a CURL handle added to a CURLM handle, thus each single
transfer might invoke callbacks. It isn't at all unlikely that programs will
use the same callback function for multiple downloads. Thus, the CURL handle
would be what connects the particular callback to which transfer.

This *could* indeed be solved by the user, since there's a custom pointer and
by using a struct a user can pass in anything they want. I just think this
seems suitable.

Getting the CURL handle in the callback isn't currently useful for much, but
I can imagine that it could be made to query for information, set options or
similar things in the future.

In the future, I'd like to see all callbacks get the CURL handle passed to
them.

So, it is more a minor adjustments for future improvements, more of a hunch
that it is the right thing than any major specific benefits right now.

> but I see that you have only one descriptor to ouput incoming, outcoming
> and informationnal data.

Yes.

> do you consider it will put too much complexity for the API user to give
> the possibility to set a different descriptor, for each type of output (and
> by the same idea a different function)?

I don't think we stop at three different kinds, as there's also different
kinds of input and output. I can think of five different kinds off the top of
my head:

 1. info text
 2. header input
 3. header output
 4. data input
 5. data output

The current VERBOSE option only shows 1 - 3 (sent to stderr with the *, < and
> prefixes).

> after that if you want to set a "<", ">" or "*" prefix, you just need to
> make a function call for each of them, taht will set the prefix in the data
> before it goes outputed

What if we instead use a prototype similar to this?

  typedef enum {
    CURLINFO_TEXT,
    CURLINFO_HEADER_IN,
    CURLINFO_HEADER_OUT,
    CURLINFO_DATA_IN,
    CURLINFO_DATA_OUT,
  } curl_infotype;

  int information(CURL *handle, /* the handle/transfer this concerns */
                  curl_infotype type /* what kind of data */
                  char *data, /* points to the data */
                  size_t size, /* size of the data pointed to */
                  void *userp); /* whatever the user please */

-- 
    Daniel Stenberg -- curl groks URLs -- http://curl.haxx.se/
Received on 2002-03-13