<div dir="ltr"><div dir="ltr">Hi all,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 9 Feb 2019 at 00:59, Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I had several thoughts about this<br>
<br>
1) yes a dedicated callback mechanism could work of course<br>
<br>
2) As Sean mentionned, and provided we redirect curl logging to our own <br>
callbacks instead of stderr, we could potentially just use the CPLDebug() <br>
infrastructure with the the callback being installed with CPLSetErrorHandler() <br>
+ CPLSetCurrentErrorHandlerCatchDebug(true). We probably wouldn't want so much <br>
debugging information to be emitted by default (both because of verbosity and <br>
performance), so this should still be conditionalized by the <br>
CPL_CURL_VERBOSE=YES config option/env. variable<br></blockquote><div><br></div><div>I'd suggest this is the best approach. Alternatively a TRACE loglevel below DEBUG like some of the Java logging frameworks have.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
3) An alternative would be to have a dedicated generic logging API<br></blockquote><div><br></div><div>Not sure this adds much over our existing logging API which already includes callbacks, and has Python integration/etc? The only thing it's really missing are logging at different levels via topic/categories, and even those are partially there atm (and you can make it work via a C++/Python logging library integration).</div><div><br></div><div>Rob :)</div></div></div>