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: Sat, 10 Sep 2022 13:44:42 +0200
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
Date: Sat, 10 Sep 2022 13:44:42 +0200
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.htmlReceived on 2022-09-10