curl / Mailing Lists / curl-library / Single Mail
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

From: Henrik Holst via curl-library <>
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.


Den fre 10 juni 2022 kl 17:33 skrev Max Dymond via curl-library <>:

> > > 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"?
> 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
> --
> Unsubscribe:
> Etiquette:

Received on 2022-06-10