Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: curl_easy_cmdline ?
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Tetetest via curl-library <curl-library_at_cool.haxx.se>
Date: Wed, 2 Dec 2020 14:46:55 +0300
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.
Date: Wed, 2 Dec 2020 14:46:55 +0300
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:tetetest_at_rambler.ru ------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2020-12-02