I am still none the wiser to what you think on this issue, though. Here are the
known facts so far:

1) The info could be sent to the DEBUGFUNCTION along with other debug info, so
that the user has control over where the redirections take him/her.

2) The info could be requested at the end of the transfer through a special
curl_easy_getinfo() option.

We have also agreed that (1) is easier to implement in libcurl than (2).

What we have to decide is which is more useful and user-friendly. Maybe we need
to hear from other libcurl developer on this issue.

BTW, I guess this is a generic problem for exposing info not currently exposed
by libcurl. If we find a generic solution then it would be easier for the future
to expose other info. Looking at the "curl_infotype" used in the DEBUGFUNCTION,
I don't think this function was designed to support returning such info.
Thinking along these lines maybe we can add (I know I will be crucified) another
callback function that returns such info during the transfer. Also would be
present extra setopt options to turn on and off certain types of info.

Thanks,

Ufuk

----- Original Message -----
From: "Daniel Stenberg" <daniel_at_haxx.se>
To: "libcurl Mailing list" <curl-library_at_lists.sourceforge.net>
Sent: Monday, January 27, 2003 12:41 PM
Subject: Re: SSL problem + request for enhancement

> On Wed, 22 Jan 2003, Ufuk Kayserilioglu wrote:
>
> > I am not very familiar with what the DEBUGFUNCTION supplies because I never
> > had to use it. However, if it is the same info output by the verbose mode
> > then maybe it is too much over head if you want just to be *informed* of
> > the URLs that are visited. I was thinking more along the lines of a
> > curl_easy_getinfo() option which returns a linked list of visited URLs. The
> > way I see it this information could very well be retrieved after the fetch
> > rather than during it.
>
> Ah, that might indeed be a fine way to do it too.
>
> > For me both ways are OK and not much problem to implement on my app side.
> > However, I guess the DEBUGFUNCTION way would be easier to code inside
> > libcurl.
>
> It would! But then again, I guess we should do things the way that causes the
> least effort for the libcurl programmers. We should concentrate on getting a
> useful and friendly API for the libcurl-users.
>
> --
> Daniel Stenberg -- curl, cURL, Curl, CURL. Groks URLs.
>
>
>

-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
Received on 2003-01-27