Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118001
Date: Sun, 19 Jun 2022 14:54:41 +0100
To: internals@lists.php.net
User-Agent: K-9 Mail for Android
In-Reply-To: <CAOfKkdTu1f6jJ2HwGjOnBR2sO6P6qdOrjH1ZzumwLzf1syXa6Q@mail.gmail.com>
References: <CAOfKkdRzoo7JuD07F8nkZBYvS5eDMiV2r6cNV-FgeLxBrdCsiQ@mail.gmail.com> <CAESVnVpzqT0xtEShqQp+FPXt2DQjeAXpkSVZTACAC0CW=8FBBg@mail.gmail.com> <CAOfKkdTu1f6jJ2HwGjOnBR2sO6P6qdOrjH1ZzumwLzf1syXa6Q@mail.gmail.com>
Message-ID: <76FA5161-16C3-4570-9EF8-B75DF2E6530A@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: =?US-ASCII?Q?Re=3A_=5BPHP-DEV=5D_Discussion_about_new_C?= =?US-ASCII?Q?url_URL_API_and_ext/curl_improvements?=
From: rowan.collins@gmail.com (Rowan Tommins)

On 19 June 2022 03:53:17 BST, Pierrick Charron <pierrick@php=2Enet> wrote:
>
>I hope you don't mind, I took some of your code from your "Enable
>strict_types checking for curl_setopt()" pull request [1] to do some test
>on introducing this but only on the OOP API=2E It's working very well [2]=
=2E
>Can I know why this PR was closed ? Any issues ? Or was it more because i=
t
>was too much of a change for the procedural API ?

While a few type errors there might be useful, it still feels a bit like p=
olishing a turd=2E=20

I count about 180 different options that can be passed to curl_setopt=2E S=
ome of them are used by nearly every user of PHP, and some are for very obs=
cure niche uses=2E Many of them are useless on their own, and exist only to=
 tweak the behaviour of some other option, or need to be used in groups lik=
e usernames and passwords=2E Others have unintuitive and unhelpful defaults=
, that need to be overridden with a different option=2E The manual page has=
 long topped the league table for user comments, currently standing at 102=
=2E It is simply not a practical design for what most users of PHP need=2E

I think one way out of this mess is to start grouping options together, an=
d providing specific methods to set them, with named, type-safe parameters=
=2E For instance, CurlHandle::setProxyOptions(string $url, ?string $authUse=
rName, ?string $authPassword, =2E=2E=2E) and so on=2E

If the long lists of parameters still feel a bit messy, we could go a step=
 further and make objects for building sets of options, with methods taking=
 short lists of genuinely dependent options, e=2Eg=2E CurlProxyOptions::set=
Auth(string $userName, string $password) and CurlProxyOptions::disableAuth(=
)

Some of the options should be rethought in the process to make more sense =
to PHP's common usage, rather than libcurl's=2E As just one example, enabli=
ng CURLOPT_VERBOSE sends some debug information to stderr, but on a web ser=
ver that is normally a log file where it will be mixed in with other inform=
ation=2E To capture it instead you need to also set CURLOPT_STDERR, which r=
equires an open file handle=2E What most users *actually* want is for that =
information to be available to them as a string after the request is execut=
ed=2E

Another thing that might be useful is some new factory methods that set se=
nsible defaults, like CurlHandle::createForHttp(string|CurlUrl $url, string=
 $method)

If we can build these things on top of the existing CurlHandle, we can rel=
ease a few things first, and progressively add features=2E Rather than havi=
ng to decide which extension to use, users will still have access to curl_s=
etopt for things there isn't a nicer interface for yet=2E We can even leave=
 it in place as something like CurlHandle::setRawOption for when users want=
 fine control of the library, or some really obscure setting=2E

Regards,

--=20
Rowan Tommins
[IMSoP]