On 9/13/21 1:01 PM, Daniel Stenberg via curl-library wrote:
I think the libcurl architecure is pretty well designed by now to
handle different and more protocols. There is however at least one
bottle neck that we need to address: the CURLPROTO_ defines.
I was thinking exactly that when developing ManageSieve.
# Ways out of this dilemma?
I can think of two ways. Neither is without a cost.
A) If we drop the < 64 bit requirement (1), we can introduce
CURLOPT_PROTOCOLS_LARGE etc that use a (guaranteed) 64 bit type and we
double room for protocols, which should be enough for the forseeable
future.
B) If we maintain the < 64 bit requirement (1), we would have to do
something like introducing a *second* protocol option for the next set
of protocols. It would be error-prone and cumbersome for users (it
will appear semi-random as to which protocols that appear in which
bitmask etc) and also inconvenient to handle internally. Perpaps one
of the bits in the first bitmask should then signal that there are
bits set in the second one. Or perhaps that's not necessary.
I can imagine an other solution. I'm afraid it breaks the ABI:
C) Spare some bits (at least 5: I did not check) by not defining the TLS
versions of CURLPROTO_* and have a global CURLPROTO_TLS for all of them.
Maybe together with macros like #define CURL_HAS_HTTPS(protobits)
(((protobits) & (CURLPROTO_HTTP | CURLPROTO_TLS)) == (CURLPROTO_HTTP |
CURLPROTO_TLS)).
Patrick
--
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
