Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127763
Date: Thu, 26 Jun 2025 21:01:39 +0200 (CEST)
To: Ben Ramsey <ramsey@php.net>, PHP Development <internals@lists.php.net>
Message-ID: <1122008041.435869.1750964499516@email.ionos.de>
In-Reply-To: <CAJOjSBjVPAaKhPaUBT5k1X3OUJd1-jjVSetfLjK3-iH9vMf6MQ@mail.gmail.com>
References: <CA+NMNO0K85acCismdBL=8vr5=nKg1_-i0BjXyiqnjoqGAnH3Xw@mail.gmail.com>
 <CAJOjSBjVPAaKhPaUBT5k1X3OUJd1-jjVSetfLjK3-iH9vMf6MQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Object-oriented curl API v2
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_435868_1186293534.1750964499514"
Importance: Normal
UI-OutboundReport: notjunk:1;M01:P0:1xdxgP80+/g=;YHZTQtQQtEjQHFO7idNNg/yAXUM
 7vP84RYnSqnAJODlg/dAhW5Wsp1Llv9d/N1RyHEjd63eWF6XutKd/uDqPtUJUuN554Ex1vj2p
 TsyXh3yZ6NDAaDwCvf72a5mtwtdKSk8tSqftbyq/3hjQm+gBKEIaC6FzG/Cd6IGs39K9SezMz
 jXtLMjZ/ap3JS2i2/ug1WrHXgPu99KObSYFmOdX9LYArFNYkI15kwRO6NV2UaRRo/Js/Vk+KQ
 9GtZA6/CKgxCDnlKqvlB2jhRncd7JDDoFwNMnc/3aDwskCOlA/P9LvSvyQE8KTzR3VQ6ylDpR
 llUnBETBu5mep6f5NqQUK1omhOc39XnljIrCBqmP8xixLdYxxtA9NlM/k779fqN5v10HevoHl
 jY2juIuAipy5h/xlJdI5v9gA9kGPiE6t3ngBi6hmjpimJkAqanS32vFJpFD5+Ur8UH+2TYNy6
 VCD+FmndpuvzcZ4mjJXLjvdERacZP8s12hrIx/zK1rbSZm2RqK68qVWB10SJzXC9gib7OeivK
 ZbU0/XJnbOOJ5kmQ8yTR45VRCgvEX7wfWtIlmrBAk0yQa3eii0hlO80PRpFMPr6nc5p4Oepzy
 Nzb1kt6+wJaTKAG6haDAt0aqQVs6GRgFYI+7vfvN6EkSxMNKELNP2SyusCZMEdlDm11Y7kAEV
 xj5GZiaBe4YjXDLwBAwY7UCnYzVG0FaL4hIDXESZPX35QGu+/xhBUVIHA22ElEQAEQ8uC06vF
 58f4NOxXl4ty4AKUr/UDEcQREL367Lv5wdHkf7OYdtSeB8t/7zZOam5wrV+StfALh6CibmOTL
 fLHxEg3ItMlR+1h0ZBTOa2cQbXdJ1brKM2vnr/Q7iCbw5rY+BS43WYxIYrR+UoFBIXK6KkFzf
 iqqeyXTiwrOnoSda69WuoHAFgD0RUSrI1lhEnsmcJnsP4kVzJHRIRtzslcO95tPvM4MlSD008
 MDypVNrKwumMk/XrejoRHkGLWcmfc8+l4qmMln2EM/ox0y6cth0M6qRePnQElhxlUHDPawfcx
 AOmXr8tfFqQwlOmpk62IVHj0F5kanWxJXZ3N+eVjNRaN962XDGdtVDKXrbOatO+Gmx3EmOqGT
 jFKy9XAqalZOM7r3sc/VK7yVNGh3PiMuutmkRKyGPsCnLJAHMMyyBy9lEzQ4/Rvmi9U/Dvnik
 wAQcsWqXb4cZimKr6ud0GscgJQqY6un+q1XyN8RvI3PtOXzZLnEDgWah82DgHzIGzXi7DKyth
 dYrsIkWnfXkZOUKIsmZQz/kt/kgqvkiVHtPNWdlxIPccnS5vxEr4GqqFdeQcy/TKi2gZhS5Uy
 6AR2i06WJmuKZq7rUEQKbDI8ETlqBv/tlxJvtedAHHhQhCGLFD1yw/o/v/OVPiB2LYYXQT+ZX
 envW18D9x+BzdfxZn42GjIJDbhMo6mE+9EGKBX3lBpNjLXLUxpwqYA3kOJUQZ2+Z+XwWYf0Tr
 l27Jwd3IqUt4oAFVjcg2iZ9aIwQv1gnZBG+PZGAWFhggEfY3VbGXHakO7cp9/zvYIQdCkw1NS
 tLxwmRgoQd1oLN+bObYaAEsyfXZGJ0uSiugZNW57
From: mails@thomasbley.de (Thomas Bley)

------=_Part_435868_1186293534.1750964499514
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

=20

> Ben Ramsey <ramsey@php.net> hat am 26.06.2025 18:54 CEST geschrieben:
> =20
> =20
> On Thu, Jun 26, 2025 at 11:27 Eric Norris <eric.t.norris@gmail.com mailto=
:eric.t.norris@gmail.com> wrote:
>=20
> > Hello Internals,
> >=20
> > I'd like to formally propose a restart of the original object-oriented
> > curl API RFC (https://wiki.php.net/rfc/curl-oop):
> >=20
> > https://wiki.php.net/rfc/curl_oop_v2
> >=20
> > 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.
> >=20
> > In a nutshell, this version of the RFC:
> >=20
> > - uses enumerations for curl options and other curl constants
> > - introduces a new Curl namespace
> >=20
> > 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.
> >=20
> > I've outlined one open question in the RFC, which relates to the above:
> >=20
> > - 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?
> >=20
> > 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.
> >=20
> > Thanks,
> > Eric
> >=20
> =20
> =20
> IMO, this sounds like something that would be great to start as a userlan=
d OOP wrapper for cURL, where it can be iterated on and the interface can b=
e tested and changed much quicker. Then, maybe proceed to an external exten=
sion that can be migrated into core later, once its interface is stable.
> =20
> cURL is massive, and there are a lot of moving parts. I wouldn=E2=80=99t =
expect to get the API correct on the first try. :-)=20
> =20
> Cheers,
> Ben
>=20
see: https://github.com/phpcurl/curlwrapper

------=_Part_435868_1186293534.1750964499514
MIME-Version: 1.0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<!doctype html>
<html>
 <head>
  <meta charset=3D"UTF-8">
 </head>
 <body>
  <div>
   &nbsp;
  </div>
  <blockquote type=3D"cite">
   <div>
    Ben Ramsey &lt;ramsey@php.net&gt; hat am 26.06.2025 18:54 CEST geschrie=
ben:
   </div>
   <div>
    &nbsp;
   </div>
   <div>
    &nbsp;
   </div>
   <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:
   </div>
   <div>
    <div class=3D"gmail_quote gmail_quote_container">
     <blockquote>
      Hello Internals,
      <br>
      <br>
      I'd like to formally propose a restart of the original object-oriente=
d
      <br>
      curl API RFC (<a href=3D"https://wiki.php.net/rfc/curl-oop" target=3D=
"_blank" rel=3D"noopener">https://wiki.php.net/rfc/curl-oop</a>):
      <br>
      <br><a href=3D"https://wiki.php.net/rfc/curl_oop_v2" target=3D"_blank=
" rel=3D"noopener">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've taken that feedback and
      <br>
      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's also the previous RFC'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'd like to get feedback on the
      <br>
      enumeration idea before committing to the work.
      <br>
      <br>
      I've outlined one open question in the RFC, which relates to the abov=
e:
      <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'm more than open to that, so please let me
      <br>
      know.
      <br>
      <br>
      Thanks,
      <br>
      Eric
     </blockquote>
     <div dir=3D"auto">
      &nbsp;
     </div>
     <div dir=3D"auto">
      &nbsp;
     </div>
     <div dir=3D"auto">
      IMO, this sounds like something that would be great to start as a use=
rland OOP wrapper for cURL, where it can be iterated on and the interface c=
an be tested and changed much quicker. Then, maybe proceed to an external e=
xtension that can be migrated into core later, once its interface is stable=
.
     </div>
     <div dir=3D"auto">
      &nbsp;
     </div>
     <div dir=3D"auto">
      cURL is massive, and there are a lot of moving parts. I wouldn=E2=80=
=99t expect to get the API correct on the first try. :-)&nbsp;
     </div>
     <div dir=3D"auto">
      &nbsp;
     </div>
     <div dir=3D"auto">
      Cheers,
     </div>
     <div dir=3D"auto">
      Ben
     </div>
    </div>
   </div>
  </blockquote>
  <div>
   see: https://github.com/phpcurl/curlwrapper
  </div>
 </body>
</html>
------=_Part_435868_1186293534.1750964499514--