Hello Daniel, Wednesday, December 2, 2020, 12:24:22 PM, you wrote:
DS> There are probably tens of thousands of authors in the world who are writing DS> applications using the libcurl API. In C, PHP, Python, perl, R and other DS> languages. Here are some points to discuss: Pros: 1. I can see only one obvious use for this feature: it gives a concise list of settings to an expert eye, which is way shorter than citing the actual code. Thus, a libcurl expert can diagnose conflicting/meaningless options easier. Cons: 1. Some options cannot be mapped to command-line (think CURLOPT_WRITEFUNCTION and friends). So if the problem is in the user's code, the function will not help diagnose it. 2. It is is only needed during debugging. I doubt that any release builds will need this feature - thus, it is going to be dead code in release builds. I'd make it optional (at least in static release builds). 3. Although the command-line can be passed to curl to reproduce the error, it is unlikely to work in other environments. Besides, libcurl can be configured in thousands of different ways, so some options may work differently on different libcurl builds. What I have in mind is mostly different SSL backends, but certainly there is more. 4. Curl options may not be familiar to libcurl API users. Maybe we should consider CURLOPT_*-related output (e.g., "PATH_AS_IS:1 PROXY:aaaa PROXYTYPE:HTTP MAXREDIRS:10 ...", etc)? We can also dump info that has no direct correspondence with curl command-line options. 5. The proposed function is consistent with libcurl ideology, but why not make it simpler? 'char* curl_easy_cmdline(CURL *easy)' - returns either pointer to the newly allocated string or NULL. 5. Maintaining the function in actual state is yet another burden. -- Best regards, Tetetest mailto:tetet...@rambler.ru ------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
