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: Henrik Holst via curl-library <curl-library_at_lists.haxx.se>
Date: Fri, 10 Jun 2022 17:36:22 +0200
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
>
Date: Fri, 10 Jun 2022 17:36:22 +0200
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.htmlReceived on 2022-06-10