On 6/5/2018 11:37 PM, Dan Fandrich wrote:
On Tue, Jun 05, 2018 at 12:42:56PM -0400, Tejas wrote:
I wasn't clear again :D
Could we have some logs for this in libcurl itself? I did some scouting, and I
think we need to do Curl_debug(...) in each case
There seems to be a lot of enums, but a script could do the hard part of
adding these logs. Would they be too verbose? (I don't mind them being too
verbose)
Any thoughts on this?
I think this would be a hard sell. libcurl logs are intended to give a view
into the inner workings of libcurl that aren't available elsewhere, but logging
the set options is easily done in the application. It would also be dozens of
log lines in many situations which would hide other, useful log entries in
their volume.
I can't comment about whether the log lines that result would hide other
useful log entries; my libcurl usage is pretty simple.
However, logging the set options is *not* easily done in the application
code. libcurl is a global package that any part of the application can
call. Even if the team leader demands that all calls to
curl_easy_setopt() go through a wrapper function so that they can be
logged, some developer somewhere will fail to follow the convention.
Additionally, application developers would be repeating
curl_easy_setopt() code in order to perform the tracking, and they would
have to extend their code every time new curl_easy_setopt() options are
added.
Status of a global resource should be tracked and reported (if it is
reported at all) within the resource. Anything else is a bug waiting to
happen. I've been burned by that (in a non-libcurl project) before.
--
David Chapman [email protected]
Chapman Consulting -- San Jose, CA
EDA Software Developer, Expert Witness
www.chapman-consulting-sj.com
2018 Chair, IEEE Consultants' Network of Silicon Valley
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
