Le 13 Mars 2002 17:41, Daniel Stenberg a écrit :
> 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 */

I'm working on that.

I choose that if you set the CURLOPT_STDERRFUNCTION to NULL, it reset the
default callback.

But in my opinion it should reset the CURLOPT_STDERR to stderr too.

Now the callback permit to set a void pointer, so it's not sure that the
CURLOPT_STDERR is a FILE *(needed by the default callback) and may cause a
crash. But in the case that the user was using a FILE * and he want to use it
again, he will be forced to set again his FILE *(by calling CURLOPT_STDERR).

So the desicion is: Do we let the possibility to the user to let crash his
application, or do we force him to set again his FILE *?

What do you think?

What do you think?

-- 
Jean-Philippe Barrette-LaPierre
Programmeur-Analyste
ProgSo Technologies
(www.progso.com)