Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127837
Precedence: bulk
MIME-Version: 1.0
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>
In-Reply-To: <CA+NMNO1G2v=PBV8L9ZZdeQJfSgRR+N6tKr7P0cpUiHGn=qZv1A@mail.gmail.com>
Reply-To: erictnorris@gmail.com
Date: Wed, 2 Jul 2025 11:48:49 -0400
Message-ID: <CA+NMNO1jJ_oiJxxwLM4q7uJSBcgK4Qt5H-r5HZYyNc7=sqRYQg@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Object-oriented curl API v2
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
From: eric.t.norris@gmail.com (Eric Norris)

> 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.
>
> 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.
>
> 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.

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.

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.

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.

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.