Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118084
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.7.0-alpha0-713-g1f035dc716-fm-20220617.001-g1f035dc7
Mime-Version: 1.0
Message-ID: <ad458894-52c5-425e-84f0-9038841ac088@www.fastmail.com>
In-Reply-To: 
 <CAOfKkdTiptR5i6+9x4UnV0sZeZh2Q8u167onzEHVwMq1Cv-E5A@mail.gmail.com>
References: 
 <CAOfKkdTjPiZHnSHuag_+fmFK-1Advh2-vfDgbJBXEmK=72NB0g@mail.gmail.com>
 <CAAKU0um7-7KZnBibwQxkvm_Kq8a264BZYOPc8G2jfax_43odjQ@mail.gmail.com>
 <CAOfKkdTiptR5i6+9x4UnV0sZeZh2Q8u167onzEHVwMq1Cv-E5A@mail.gmail.com>
Date: Fri, 24 Jun 2022 09:27:45 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] [RFC] [Under Discussion] New Curl URL API
From: larry@garfieldtech.com ("Larry Garfield")

On Fri, Jun 24, 2022, at 8:49 AM, Pierrick Charron wrote:
> Hi all, and thanks Levi for your feedback,
>
> If you look at the first thread (Discussion about new Curl URL API and
> ext/curl improvements) you'll see that this was my first approach. I even
> proposed to "OOPify" the actual CurlHandle & co objects with "simple"
> methods like $ch->setOpt(). Anyone who reads the actual API can see this is
> the actual "philosophy" of the extension. It was designed (on purpose or
> not) as a thin wrapper over curl. But lets focus on URL API only !
>
> With previous thread answers, I was under the impression that I really was
> the only one liking the approach of following the cURL api as much as
> possible and leaving the more high level API to things like Guzzle & co
> (for example by adding an Implementation of PSR-7 UriInterface using this
> API) since all the others parts of the API are done this way. I think it's
> important to have this new Curl URL API in 8.2 since it fixes security
> issues and that's of course not ideal but I would rather have an
> implementation that would not be my first choice, than not having it at all.
>
> What do you think ? I would love more people to give feedback on what they
> are expecting, if they don't care if they prefer one approach or the other
> and of course why ? I was thinking about doing a vote on this, but I'm not
> sure it's a good idea. What do you all think ?
>
> Regards,
> Pierrick

The root question, I think, is who the consumer is for this RFC?

Is the consumer PHP developers?  Then it should be a good PHP API.

Is the consumer the Guzzle team and everyone else just uses Guzzle and ignores Curl/CurlUrl?  Then it should probably adhere as closely as feasible to Curl's API, awful as it is, and be documented out the wazoo.

There likely isn't time for 8.2 to do the first option, but probably is for the second.

--Larry Garfield