Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127760
Precedence: bulk
MIME-Version: 1.0
References: <CA+NMNO0K85acCismdBL=8vr5=nKg1_-i0BjXyiqnjoqGAnH3Xw@mail.gmail.com>
In-Reply-To: <CA+NMNO0K85acCismdBL=8vr5=nKg1_-i0BjXyiqnjoqGAnH3Xw@mail.gmail.com>
Date: Thu, 26 Jun 2025 11:54:42 -0500
Message-ID: <CAJOjSBjVPAaKhPaUBT5k1X3OUJd1-jjVSetfLjK3-iH9vMf6MQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Object-oriented curl API v2
To: PHP Development <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000009b8af306387c6b12"
From: ramsey@php.net (Ben Ramsey)

--0000000000009b8af306387c6b12
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 26, 2025 at 11:27 Eric Norris <eric.t.norris@gmail.com> wrote:

> Hello Internals,
>
> I'd like to formally propose a restart of the original object-oriented
> curl API RFC (https://wiki.php.net/rfc/curl-oop):
>
> https://wiki.php.net/rfc/curl_oop_v2
>
> The prior RFC seemed to get positive feedback, with a small consensus
> around wanting enum(s) for curl options. I've taken that feedback and
> incorporated it into a new RFC, as I am not the original author, but I
> am interested in making another potential improvement to the curl
> extension.
>
> In a nutshell, this version of the RFC:
>
> - uses enumerations for curl options and other curl constants
> - introduces a new Curl namespace
>
> I have not yet created an implementation PR. I realize that is
> somewhat discouraged, but I believe that this should be relatively
> straightforward to implement (there's also the previous RFC's PR to
> build on top of). The implementation of this RFC as it is now will
> likely be tedious, however, so I'd like to get feedback on the
> enumeration idea before committing to the work.
>
> I've outlined one open question in the RFC, which relates to the above:
>
> - Should we organize the curl option enumerations by value type? Or
> have a single enumeration for all curl_setopt options and another for
> all curl_multi_setopt options?
>
> If others (including the original RFC author) are interested in
> working with me on this, I'm more than open to that, so please let me
> know.
>
> Thanks,
> Eric



IMO, this sounds like something that would be great to start as a userland
OOP wrapper for cURL, where it can be iterated on and the interface can be
tested and changed much quicker. Then, maybe proceed to an external
extension that can be migrated into core later, once its interface is
stable.

cURL is massive, and there are a lot of moving parts. I wouldn=E2=80=99t ex=
pect to
get the API correct on the first try. :-)

Cheers,
Ben

--0000000000009b8af306387c6b12
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div>On Thu, Jun 26, 2025 at 11:27 Eric Norris &lt;<a href=3D"mailto:eric.t=
.norris@gmail.com">eric.t.norris@gmail.com</a>&gt; wrote:<br></div><div><di=
v class=3D"gmail_quote gmail_quote_container"><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-st=
yle:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">Hello Intern=
als,<br>
<br>
I&#39;d like to formally propose a restart of the original object-oriented<=
br>
curl API RFC (<a href=3D"https://wiki.php.net/rfc/curl-oop" rel=3D"noreferr=
er" target=3D"_blank">https://wiki.php.net/rfc/curl-oop</a>):<br>
<br>
<a href=3D"https://wiki.php.net/rfc/curl_oop_v2" rel=3D"noreferrer" target=
=3D"_blank">https://wiki.php.net/rfc/curl_oop_v2</a><br>
<br>
The prior RFC seemed to get positive feedback, with a small consensus<br>
around wanting enum(s) for curl options. I&#39;ve taken that feedback and<b=
r>
incorporated it into a new RFC, as I am not the original author, but I<br>
am interested in making another potential improvement to the curl<br>
extension.<br>
<br>
In a nutshell, this version of the RFC:<br>
<br>
- uses enumerations for curl options and other curl constants<br>
- introduces a new Curl namespace<br>
<br>
I have not yet created an implementation PR. I realize that is<br>
somewhat discouraged, but I believe that this should be relatively<br>
straightforward to implement (there&#39;s also the previous RFC&#39;s PR to=
<br>
build on top of). The implementation of this RFC as it is now will<br>
likely be tedious, however, so I&#39;d like to get feedback on the<br>
enumeration idea before committing to the work.<br>
<br>
I&#39;ve outlined one open question in the RFC, which relates to the above:=
<br>
<br>
- Should we organize the curl option enumerations by value type? Or<br>
have a single enumeration for all curl_setopt options and another for<br>
all curl_multi_setopt options?<br>
<br>
If others (including the original RFC author) are interested in<br>
working with me on this, I&#39;m more than open to that, so please let me<b=
r>
know.<br>
<br>
Thanks,<br>
Eric</blockquote><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><d=
iv dir=3D"auto">IMO, this sounds like something that would be great to star=
t as a userland OOP wrapper for cURL, where it can be iterated on and the i=
nterface can be tested and changed much quicker. Then, maybe proceed to an =
external extension that can be migrated into core later, once its interface=
 is stable.</div><div dir=3D"auto"><br></div><div dir=3D"auto">cURL is mass=
ive, and there are a lot of moving parts. I wouldn=E2=80=99t expect to get =
the API correct on the first try. :-)=C2=A0</div><div dir=3D"auto"><br></di=
v><div dir=3D"auto">Cheers,</div><div dir=3D"auto">Ben</div><div dir=3D"aut=
o"><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border=
-left-color:rgb(204,204,204)" dir=3D"auto"></blockquote></div></div>

--0000000000009b8af306387c6b12--