Re: Deprecating 4 "wrong" RTMP protocol bits

From: Timothe Litt <litt_at_acm.org>
Date: Fri, 10 Jun 2022 14:14:55 -0400

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>:
>
> > > 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.html

Received on 2022-06-10