Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127838
Content-Type: multipart/signed;
	boundary="Apple-Mail=_0411E513-FEAC-4501-A3CB-5352657AD5F7";
	protocol="application/pgp-signature";
	micalg=pgp-sha256
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.600.51.1.1\))
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Object-oriented curl API v2
Date: Wed, 2 Jul 2025 10:59:33 -0500
References: <CA+NMNO0K85acCismdBL=8vr5=nKg1_-i0BjXyiqnjoqGAnH3Xw@mail.gmail.com>
 <CANLbj-ppn+QtYij2uHXmNvbXckKzz84fkj6f-6iw_7wioFN0dA@mail.gmail.com>
 <ab051ed8-8961-4074-b5e7-2abbfd272ef4@app.fastmail.com>
 <CA+NMNO1G2v=PBV8L9ZZdeQJfSgRR+N6tKr7P0cpUiHGn=qZv1A@mail.gmail.com>
 <CA+NMNO1jJ_oiJxxwLM4q7uJSBcgK4Qt5H-r5HZYyNc7=sqRYQg@mail.gmail.com>
To: php internals <internals@lists.php.net>
In-Reply-To: <CA+NMNO1jJ_oiJxxwLM4q7uJSBcgK4Qt5H-r5HZYyNc7=sqRYQg@mail.gmail.com>
Message-ID: <CD53A9CE-9FE1-439F-ADB3-F274DF79EDD0@php.net>
From: ramsey@php.net (Ben Ramsey)


--Apple-Mail=_0411E513-FEAC-4501-A3CB-5352657AD5F7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

> On Jul 2, 2025, at 10:48, Eric Norris <eric.t.norris@gmail.com> wrote:
>=20
>> Based on the feedback so far (I do plan on waiting for more responses
>> to your email), and on my own preferences, I wonder if there is a
>> hybrid option I could propose. Perhaps the RFC could offer both a
>> \Curl\Handle (tentative name) to address position 1, and a
>> \Curl\BasicHttpHandle (also tentative name) that addresses position =
2?
>> If people were amenable, I'd even make the BasicHttpHandle a separate
>> vote.
>>=20
>> I agree that 3 is both more bikesheddable and also possibly ideal, =
but
>> I feel my above suggestion maybe strikes the right balance between =
the
>> "status quo is fine, I don't want to see random HTTP-related methods
>> on my low(est)-level curl object" and the "I'd like to do basic HTTP
>> stuff with curl, without a library" crowds.
>>=20
>> Barring that, my preference would be 2, but I'd accept 1 just to have
>> it pass - like I mentioned elsewhere, I think there is value in
>> introducing namespaces and object-oriented APIs for "modernization"
>> and language consistency reasons.
>=20
> Having thought about this some more, while I'm still feeling somewhat
> positive about my suggestion I'm just not sure it's the best way to
> proceed. I started to sketch what a BasicHttpHandle class would look
> like, and I'm stuck on how to get data about the response out of the
> class.
>=20
> Naively, we could have $response_status_code and $response_headers
> properties, and have the same fetch() and execute() methods I
> suggested elsewhere to get the response body. Alternatively, we could
> return a simple CurlHttpResponse object which contains all three
> properties in the fetch() and execute() implementations for the
> BasicHttpHandle class.
>=20
> Both of these are fine, but they would lock us out of being PSR7
> compatible. I think that people would probably desire PSR7
> compatibility, and I would feel uncomfortable with eliminating or
> tainting the possibility of achieving this. For example, if we had
> this BasicHttpHandle and then later introduced PSR7 response objects,
> we'd need to either break backwards compatibility for the class, or
> introduce a second class. We could also go straight to returning a
> PSR7 compatible response for the BasicHttpHandle class, but I think
> that likely deserves its own RFC.
>=20
> So in closing, if people felt generally okay with the limitation of
> not being PSR7 compatible, I'd probably still add some form of my
> BasicHttpHandle suggestion as a secondary vote. If people thought PSR7
> was necessary, I'd drop it, and leave a PSR7-in-core RFC for the
> future. In that case, I'd go with Larry's option 1 for the RFC; I've
> currently updated the RFC to match that option for now.


I think it=E2=80=99s good to keep PSR-7 in mind when designing the =
interface, but I don=E2=80=99t think it=E2=80=99s necessary to strive =
for 100% compatibility. Userland will end up writing wrappers for it =
that implement PSR-7. IMO, the interface should attempt to more closely =
follow curl nomenclature and idioms, since it=E2=80=99s an interface for =
interacting with curl.

Cheers,
Ben



--Apple-Mail=_0411E513-FEAC-4501-A3CB-5352657AD5F7
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iHUEAREIAB0WIQToXQMR3fpbrPOmEOewLZeYnIwHGwUCaGVXZQAKCRCwLZeYnIwH
G/OnAPwKgqPewksdKd6dAItVHXrfszAbay328cQIhCyPtb1V6wD+JmfljQv8529C
TP8uwbTFKNl2NfruLsm7NB444Zc7T84=
=1zGu
-----END PGP SIGNATURE-----

--Apple-Mail=_0411E513-FEAC-4501-A3CB-5352657AD5F7--