Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127761
Precedence: bulk
MIME-Version: 1.0
References: <CA+NMNO0K85acCismdBL=8vr5=nKg1_-i0BjXyiqnjoqGAnH3Xw@mail.gmail.com>
 <CAJOjSBjVPAaKhPaUBT5k1X3OUJd1-jjVSetfLjK3-iH9vMf6MQ@mail.gmail.com>
In-Reply-To: <CAJOjSBjVPAaKhPaUBT5k1X3OUJd1-jjVSetfLjK3-iH9vMf6MQ@mail.gmail.com>
Reply-To: erictnorris@gmail.com
Date: Thu, 26 Jun 2025 13:21:19 -0400
Message-ID: <CA+NMNO1tpp5dNANbx88G1x=cdgiabCKLLL0n9KLaAWgvBo3_qw@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Object-oriented curl API v2
To: Ben Ramsey <ramsey@php.net>
Cc: PHP Development <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: eric.t.norris@gmail.com (Eric Norris)

> 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.
>
> 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. :-)
>
> Cheers,
> Ben

(Apologies for the double-post Ben, I'm a little rusty and forgot to reply-=
all)

I see, thanks for your feedback! To clarify, I am not aiming to
produce a high-level API for curl. I would expect that most users
would still reach for libraries like Guzzle, etc.

I know that in the prior discussion, Rowan Tommins had a vision for a
high-level API (https://externals.io/message/122371#122424), but I
share your sentiment that this would be difficult to get right in
core. I'd prefer to aim for a (mostly) direct translation of the
low-level API, which I think still has benefits on its own.