I just realized that the "pre_execute_transfer(handle)" mechanism is not going
to help to handle "system" issues as we don't have a mechanism to get a value
of some specific option when transfer is set and about to run.
We have curl_easy_setopt() but not curl_easy_getopt(), so there is no easy way
to get some option value in global functions like
"pre_execute_transfer(handle)" if we just have a transfer handle there.
Asking to provide curl_easy_getopt(), in addition to pre_execute_transfer()
mechanism will be probably too much for tuning just a few "system" settings.
Also, "system" tuning may not necessarily be always done by intercepting and
changing some transfer options.
So, for tuning just a few "system" settings, I am thinking that maybe we can
have something like:
curl_global_init_system(long flags, curl_system_funcs *system_funcs);
struct curl_system_funcs {
curl_ipv6works ipv6_works; // Function checking if IPv6 works on the system
// Add more system functions here allowing to override defaults and tune
some specific system
};
This approach covers IPv6 tuning and it is general enough to add more "system"
functions in the future without a need to add more new curl_global_init_xxx()
global functions.
Thanks,
Dmitry Karpov
-----Original Message-----
From: curl-library <[email protected]> On Behalf Of Dmitry
Karpov via curl-library
Sent: Monday, September 26, 2022 3:48 PM
To: Daniel Stenberg <[email protected]>
Cc: Dmitry Karpov <[email protected]>; Dmitry Karpov via curl-library
<[email protected]>
Subject: RE: [EXTERNAL] Re: Feature request: provide ability to set a global
callback function telling libcurl if IPv6 works on the system
> 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.
Exactly. The "system" level is what is needed to customize the "system"
behavior for all the handles created in the libcurl application without
touching the end client application code (regardless of whether it is opened
for modification or not).
The "system" level tweaks will allow to adjust libcurl-based code to run the
best possible way for some particular system (HW platform, OS kernel etc)
trying to satisfy the "intent" expressed in the transfer setup code as much as
possible.
> 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.
I think that the fundamental problem I am trying to solve can be expressed as
follows:
"How to apply some settings on all handles created by the application
(including its integrated components using libcurl) without touching the code
that sets them,
because it is not always easy or feasible to change the transfer
setting code."
In my particular case, it is "IPv6 works" check which affects how the "resolve
mode" option should be applied.
But there may be some other transfer settings that also need some tuning for
some particular "system".
I guess such "system" functionality requires using global callbacks with all
problems and limitations that it brings for all those adventurous folks who
would dare to use that functionality.
And if we look at this problem from a wider perspective, then all settings can
be tuned for some system if libcurl provides a just one "system" global
callback which can examine and modify all the options set for the transfer
before libcurl executes it.
Something like "pre_execute_transfer(CURL* easy_handle, void* data)" (and maybe
"pre_execute_multi_transfer(CURLM* multi_handle, void* data) to tune
multi-transfers)" .
These callbacks or "hooks", if set, will allow applications to adjust their
"system" behavior for a wide range of options - not just for checking if "IPv6
works" without touching end client code (which they might not be able to
change).
They will also help to address some security or policy issues when some when
integrated components may use some transfer settings which are against some
policies enforced in the "hosting" applications.
What do you think about that approach?
It still introduces new global callback(s), but the flexibility that this
approach brings in allows to do a wide range of "system" customizations beyond
just IPv6.
Thanks,
Dmitry Karpov
-----Original Message-----
From: Daniel Stenberg <[email protected]>
Sent: Monday, September 26, 2022 2:52 PM
To: Dmitry Karpov <[email protected]>
Cc: Dmitry Karpov via curl-library <[email protected]>
Subject: RE: [EXTERNAL] Re: Feature request: provide ability to set a global
callback function telling libcurl if IPv6 works on the system
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.html
--
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
