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: [EXTERNAL] Re: Feature request: provide ability to set a global callback function telling libcurl if IPv6 works on the system
- 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, 26 Sep 2022 23:52:05 +0200 (CEST)
On Mon, 26 Sep 2022, Dmitry Karpov wrote:
> Your proposal for fixing problem with the default "IPv6 works" function is
> to move the problem from the "system" level to the "client" level and make
> clients aware of which "platform" (HW, kernel version etc) they may running
> on and use platform-specific "IPv6 works" function in all places where
> transfer is set.
I think your idea of two separate levels, system and client, is interesting,
and it could be worth exploring.
I could imagine a concept where you create a "system" from which you make
easy handles, as then the "system" could define things that all subsequently
created easy handles inherit. Like IPv6 functionality.
system = curl_system_init();
easy = curl_easy_init_system(system);
which possibly could be faked pretty good today with:
system = curl_easy_init()
easy = curl_easy_duphandle(system);
an alernative could be to (somehow) store easy options for a specified scope
within a multi handle, so when you create new easy handles for use in a
certain multi handle you could:
easy = curl_easy_inherit(multi);
I think my main problems with your current design proposal is that your
"system level" is global (with all the problems and limitations that brings)
and that it needs to use a callback for information that really isn't needed
to be set by a callback. Details that are the direct results of your
introduciton of these separated levels without libcurl actually having any
such separation of priviledges and now you have to shoehorn them in and then
it can't be done in a very clean way.
> And if documenting, publishing etc is a hassle then can we make it
> "undocumented API" then?
No, that's just worse. We either have an API or we do not. If we have it, we
support it completely and it needs to be fully documented so that everyone
knows what to expect from it, and it needs to be tested. Otherwise it will
lead to security problems and that we accidentally slightly break behavior in
a future with the following sad faces.
Every function we add has a weight and a cost. It adds code, it adds docs, it
adds tests and it adds to the haystack for people trying to find their
needles. It is our duty to always resist adding more. Until we are convinced
we need to add the new stuff.
Date: Mon, 26 Sep 2022 23:52:05 +0200 (CEST)
On Mon, 26 Sep 2022, Dmitry Karpov wrote:
> Your proposal for fixing problem with the default "IPv6 works" function is
> to move the problem from the "system" level to the "client" level and make
> clients aware of which "platform" (HW, kernel version etc) they may running
> on and use platform-specific "IPv6 works" function in all places where
> transfer is set.
I think your idea of two separate levels, system and client, is interesting,
and it could be worth exploring.
I could imagine a concept where you create a "system" from which you make
easy handles, as then the "system" could define things that all subsequently
created easy handles inherit. Like IPv6 functionality.
system = curl_system_init();
easy = curl_easy_init_system(system);
which possibly could be faked pretty good today with:
system = curl_easy_init()
easy = curl_easy_duphandle(system);
an alernative could be to (somehow) store easy options for a specified scope
within a multi handle, so when you create new easy handles for use in a
certain multi handle you could:
easy = curl_easy_inherit(multi);
I think my main problems with your current design proposal is that your
"system level" is global (with all the problems and limitations that brings)
and that it needs to use a callback for information that really isn't needed
to be set by a callback. Details that are the direct results of your
introduciton of these separated levels without libcurl actually having any
such separation of priviledges and now you have to shoehorn them in and then
it can't be done in a very clean way.
> And if documenting, publishing etc is a hassle then can we make it
> "undocumented API" then?
No, that's just worse. We either have an API or we do not. If we have it, we
support it completely and it needs to be fully documented so that everyone
knows what to expect from it, and it needs to be tested. Otherwise it will
lead to security problems and that we accidentally slightly break behavior in
a future with the following sad faces.
Every function we add has a weight and a cost. It adds code, it adds docs, it
adds tests and it adds to the haystack for people trying to find their
needles. It is our duty to always resist adding more. Until we are convinced
we need to add the new stuff.
-- / 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.se/mail/etiquette.htmlReceived on 2022-09-26