On 9/13/21 13:01, Daniel Stenberg via curl-library wrote:
Hi team.
We added support for GOPHERS in late 2020. There's a new PR proposing
support for the ManageSieve protocol. We had a PR previously
suggesting Gemini support and the other day ICAP was brought up in a
discussion. WebSockets is another common one discussed.
I don't think it's crazy to imagine that we might add support for more
protocols going forward. Sooner or later.
This is not a problem we must solve *right now*, but I would feel
better if we have an idea about how to address it when we get there.
Because I'm convinced we will reach this point eventually.
One year later, all protocol bits are used !
In the meantime, CURLOPT_PROTOCOLS_STR has been added for caller's use,
but this only translates to bits and the internal problem has not been
resolved yet.
IMO, using strings internally is much too expensive in overhead.
Do we have now an idea how we want to extend this internally ?
- Use a packed struct of bools. Requires C99 for initialization. Very
clear code for constant protocols but hard to access for a run-time
computed protocol number.
- Use an array of 8-bit flags. Also requires C99 for initialization.
- Use a packed array of flags. Almost impossible to initialize statically.
- Use an array of protocol numbers. High run-time overhead.
- Drop support for non-64bit curl_off_t.
- Use a struct with a second set of flags (named CURLPROTO2_*)
- Something else...
Adding another protocol will only be possible after this problem is
resolved.
I could look at it for an implementation if I knew in which direction to go.
BTW: the websockets protocols are not (yet) handled by protocol2num().
Patrick
--
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
