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: Above and beyond 32 protocols
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Patrick Monnerat via curl-library <curl-library_at_lists.haxx.se>
Date: Mon, 13 Sep 2021 17:09:47 +0200
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
Date: Mon, 13 Sep 2021 17:09:47 +0200
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.htmlReceived on 2021-09-13