Daniel, I think I am repeating my arguments because some problems that you
solution brings in are not addressed.
Even it is very painful to change transfer setup code in all the places to
utilize your fix for IPv4 mode, it is at least doable.
But how do you suggest to address the issues with "closed code" as I outlined
in my previous post?
" - if you code integrates (or will do that future) some "3rd party"
components which might be using libcurl and dual-stack resolve modes, which you
can't modify"
The integrated code if it uses dual-stack resolve modes cannot be covered by
your solution and connection delays will remain there.
Such code cannot be always modified, especially if it comes in binaries.
I have such code in my applications, and someone else may have such code as
well.
Also, how do you suggest to address the problem I outlined in my previous post
which your PR introduced?
"This "lazy" approach doesn't allow to create a multi-handle ahead of time
to avoid delays on dual-stack connections."
The previous mechanism at least allowed to do that to mitigate the
Curl_ipv6works() delays, but not any more after the PR is integrated.
> I have not been convinced that we need to add a new way to say IPv6 doesn't
> work.
I don't understand why do you call my proposal "a new way"?
It is fundamentally the same old way with an extended option to provide an
application-specific way to detect that IPv6 doesn't work on the system.
I guess your PR can be called a "new way" as the penalty for Curl_ipv6works()
delays from now on will always be paid for dual-stack connections unless
someone will implement this cumbersome mechanism of applying custom "IPv6
works" detection on every dual-stack transfer setup if it is possible (and
still have delays when it is not possible to modify the code).
I don't want to argue about simplicity of both approaches, but I think that
side-by-side comparison really tells which approach is simpler and easier to
use.
Thanks,
Dmitry Karpov
-----Original Message-----
From: Daniel Stenberg <[email protected]>
Sent: Friday, September 23, 2022 3:10 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 Fri, 23 Sep 2022, Dmitry Karpov wrote:
> This would create the same outcome ONLY after your PR fixing IPv4 mode is
> applied.
Source code changes tend to work like that: they only have an effect after they
are actually applied. And my PR is already merged.
I'm sorry, but I think you are repeating your arguments and while I could
repeat my arguments again as a reponse I don't think it would drive the
discussion forward.
I have not been convinced that we need to add a new way to say IPv6 doesn't
work.
--
/ 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
