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: Feature request about curlinfo option returning resolver status/error code
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>
Date: Mon, 25 Apr 2022 00:41:07 +0200 (CEST)
On Fri, 22 Apr 2022, Dmitry Karpov via curl-library wrote:
> So, a very simple info option, like CURLINFO_RESOLVER_CODE returning a
> resolver status code “as is” provides useful debugging information needed to
> debug resolver issues but without any maintenance cost on libcurl side.
Everything we provide has a maintenance cost.
This suggested option will have a cost too if it should have a functionality.
For example, we need to document the values it can return and then we need to
maintain those values in future releases. Applications will assume and depend
on the values to be solid.
We also want to avoid to force applications to need to know about specific
libcurl backends and rather keep the API agnostic, but this proposal goes
against that. This adds friction to the API.
So we really need to think that this feature brings at least as much as value
as the cost.
Does it?
Date: Mon, 25 Apr 2022 00:41:07 +0200 (CEST)
On Fri, 22 Apr 2022, Dmitry Karpov via curl-library wrote:
> So, a very simple info option, like CURLINFO_RESOLVER_CODE returning a
> resolver status code “as is” provides useful debugging information needed to
> debug resolver issues but without any maintenance cost on libcurl side.
Everything we provide has a maintenance cost.
This suggested option will have a cost too if it should have a functionality.
For example, we need to document the values it can return and then we need to
maintain those values in future releases. Applications will assume and depend
on the values to be solid.
We also want to avoid to force applications to need to know about specific
libcurl backends and rather keep the API agnostic, but this proposal goes
against that. This adds friction to the API.
So we really need to think that this feature brings at least as much as value
as the cost.
Does it?
-- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://curl.se/support.html
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2022-04-25