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: Deprecating 4 "wrong" RTMP protocol bits
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Steve Holme via curl-library <curl-library_at_lists.haxx.se>
Date: Fri, 10 Jun 2022 15:25:54 +0000
On Fri, 10 June 2022, Daniel Stenberg wrote:
> I want to add two new protocols to libcurl soon (for websockets) but there is no room left in the
> CURLOPT_PROTO bitmask within 32 bits.
>
> The main reason there is no room left, in spite of curl only supporting 26 protocols, is that RTMP
> occupies *6* slots in that bitmask. I consider that a mistake, but a mistake that is done in the public
> API so changing it is a bit risky.
Even with that change that only gives us expandability for two more protocols in the future and then we are in the same position ☹
> If anyone has a better idea on how to solve this challenge, then let me know!
Should we take the opportunity to create a replacement to CURLOPT_PROTOCOLS and deprecate that?
Off the top of my head a replacement could be:
* A 64-bit value - I appreciate I've been out of the curl game a while so are 64-bit options fully supported on all platforms now, for example, are 64-bit options still a 'long' which on LLP64 platforms is an issue?
* A structure, which might include the base protocol, whether it is TLS or not, etc...
Kind Regards
Steve
Date: Fri, 10 Jun 2022 15:25:54 +0000
On Fri, 10 June 2022, Daniel Stenberg wrote:
> I want to add two new protocols to libcurl soon (for websockets) but there is no room left in the
> CURLOPT_PROTO bitmask within 32 bits.
>
> The main reason there is no room left, in spite of curl only supporting 26 protocols, is that RTMP
> occupies *6* slots in that bitmask. I consider that a mistake, but a mistake that is done in the public
> API so changing it is a bit risky.
Even with that change that only gives us expandability for two more protocols in the future and then we are in the same position ☹
> If anyone has a better idea on how to solve this challenge, then let me know!
Should we take the opportunity to create a replacement to CURLOPT_PROTOCOLS and deprecate that?
Off the top of my head a replacement could be:
* A 64-bit value - I appreciate I've been out of the curl game a while so are 64-bit options fully supported on all platforms now, for example, are 64-bit options still a 'long' which on LLP64 platforms is an issue?
* A structure, which might include the base protocol, whether it is TLS or not, etc...
Kind Regards
Steve
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2022-06-10