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: Dmitry Karpov via curl-library <curl-library_at_lists.haxx.se>
Date: Fri, 10 Jun 2022 18:47:25 +0000
I would like to suggest keeping CURLOPT_PROTOCOLS as it is now (which holds bitmap of the existing protocols) and add CURLOPT_PROTOCOLS1 to store bits for future protocols.
When it gets exhausted, CURLOPT_PROTOCOLS2 can be added and so on.
On the “info” side, we would need to add a similar new info option like CURLINFO_PROTOCOL1 etc to check new protocols.
We can also add “extended” protocol bit (representing CURLPROTO_EXTENDED) to the protocol bitmask, which will indicate to the client that it needs to use the next “CURLINFO_PROTOCOL” option, like CURLINFO_PROTOCOL1 to check for the new protocol.
So, for a new protocol like “websocket” client will use CURLOPT_PROTOCOLS1 option to set CURLPROTO_WS, and the CURLINFO_PROTOCOL will return CURLPROTO_EXTENDED in this case.
Then client may use CURLINFO_PROTOCOL1 and check CURLPROTO_WS bit to test if WebSocket was used as one of the “extended” protocols.
This approach will allow to keep current clients unchanged and easily add new protocols in the future.
Thanks,
Dmitry Karpov
From: curl-library <curl-library-bounces_at_lists.haxx.se> On Behalf Of Timothe Litt via curl-library
Sent: Friday, June 10, 2022 11:15 AM
To: curl-library_at_lists.haxx.se
Cc: Timothe Litt <litt_at_acm.org>
Subject: Re: Deprecating 4 "wrong" RTMP protocol bits
I like a comma separated string: "https,imaps" is even easier to type than CURLPROTO_HTTPS|CURLPROTO_IMAPS
You'd also need to do the same for CURLINFO_PROTOCOL (get the protocol used).
BTW: Doc error: https://curl.se/libcurl/c/CURLINFO_PROTOCOL.html says "to receive the version"; I think "to receive the protocol" is intended.
I wouldn't want a get supported protocols (e.g. curl-config --protocols) api to return a comma-separated list; that's work for the caller to parse. Perhaps that should return a (NULL-terminated) list of pointers to strings (names of the supported protocols). It's a pretty short list, but if you guarantee that it's sorted, one can check for support with a binary search.
And/or a simple bool = curl_is_protocol_supported("dict") - I don't think this needs to support a list. (Among other reasons, because I can't decide if a list would be "or" or "and". And if "or", I'd want to know which ones... Let the application decide.) Anyhow, with bsearch(), it would be fast enough.
Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
On 10-Jun-22 11:36, Henrik Holst via curl-library wrote:
a comma separated string would be the fully future compatible option unless 64 (long long should work for LLP64) is enough for the unknown future. The internal representation could still be a bitfield for performance reasons, but the public API should probably be a more future proof one.
/HH
Den fre 10 juni 2022 kl 17:33 skrev Max Dymond via curl-library <curl-library_at_lists.haxx.se<mailto:curl-library_at_lists.haxx.se>>:
> > 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...
Perhaps simply "a string"? https://github.com/curl/curl/blob/master/src/tool_libinfo.c already converts a proto name (e.g. "https", "sftp") into a value - I don't think it's beyond the realms of feasibility to have a similar API to replace CURLOPT_PROTOCOLS.
--
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Date: Fri, 10 Jun 2022 18:47:25 +0000
I would like to suggest keeping CURLOPT_PROTOCOLS as it is now (which holds bitmap of the existing protocols) and add CURLOPT_PROTOCOLS1 to store bits for future protocols.
When it gets exhausted, CURLOPT_PROTOCOLS2 can be added and so on.
On the “info” side, we would need to add a similar new info option like CURLINFO_PROTOCOL1 etc to check new protocols.
We can also add “extended” protocol bit (representing CURLPROTO_EXTENDED) to the protocol bitmask, which will indicate to the client that it needs to use the next “CURLINFO_PROTOCOL” option, like CURLINFO_PROTOCOL1 to check for the new protocol.
So, for a new protocol like “websocket” client will use CURLOPT_PROTOCOLS1 option to set CURLPROTO_WS, and the CURLINFO_PROTOCOL will return CURLPROTO_EXTENDED in this case.
Then client may use CURLINFO_PROTOCOL1 and check CURLPROTO_WS bit to test if WebSocket was used as one of the “extended” protocols.
This approach will allow to keep current clients unchanged and easily add new protocols in the future.
Thanks,
Dmitry Karpov
From: curl-library <curl-library-bounces_at_lists.haxx.se> On Behalf Of Timothe Litt via curl-library
Sent: Friday, June 10, 2022 11:15 AM
To: curl-library_at_lists.haxx.se
Cc: Timothe Litt <litt_at_acm.org>
Subject: Re: Deprecating 4 "wrong" RTMP protocol bits
I like a comma separated string: "https,imaps" is even easier to type than CURLPROTO_HTTPS|CURLPROTO_IMAPS
You'd also need to do the same for CURLINFO_PROTOCOL (get the protocol used).
BTW: Doc error: https://curl.se/libcurl/c/CURLINFO_PROTOCOL.html says "to receive the version"; I think "to receive the protocol" is intended.
I wouldn't want a get supported protocols (e.g. curl-config --protocols) api to return a comma-separated list; that's work for the caller to parse. Perhaps that should return a (NULL-terminated) list of pointers to strings (names of the supported protocols). It's a pretty short list, but if you guarantee that it's sorted, one can check for support with a binary search.
And/or a simple bool = curl_is_protocol_supported("dict") - I don't think this needs to support a list. (Among other reasons, because I can't decide if a list would be "or" or "and". And if "or", I'd want to know which ones... Let the application decide.) Anyhow, with bsearch(), it would be fast enough.
Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
On 10-Jun-22 11:36, Henrik Holst via curl-library wrote:
a comma separated string would be the fully future compatible option unless 64 (long long should work for LLP64) is enough for the unknown future. The internal representation could still be a bitfield for performance reasons, but the public API should probably be a more future proof one.
/HH
Den fre 10 juni 2022 kl 17:33 skrev Max Dymond via curl-library <curl-library_at_lists.haxx.se<mailto:curl-library_at_lists.haxx.se>>:
> > 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...
Perhaps simply "a string"? https://github.com/curl/curl/blob/master/src/tool_libinfo.c already converts a proto name (e.g. "https", "sftp") into a value - I don't think it's beyond the realms of feasibility to have a similar API to replace CURLOPT_PROTOCOLS.
--
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2022-06-10