Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118082
Message-ID: <c860a2fd-be16-f295-ff56-c78a998e153e@bastelstu.be>
Date: Fri, 24 Jun 2022 16:13:34 +0200
MIME-Version: 1.0
Content-Language: en-US
To: Pierrick Charron <pierrick@php.net>,
 Levi Morrison <levi.morrison@datadoghq.com>
Cc: PHP internals <internals@lists.php.net>
References: <CAOfKkdTjPiZHnSHuag_+fmFK-1Advh2-vfDgbJBXEmK=72NB0g@mail.gmail.com>
 <CAAKU0um7-7KZnBibwQxkvm_Kq8a264BZYOPc8G2jfax_43odjQ@mail.gmail.com>
 <CAOfKkdTiptR5i6+9x4UnV0sZeZh2Q8u167onzEHVwMq1Cv-E5A@mail.gmail.com>
In-Reply-To: <CAOfKkdTiptR5i6+9x4UnV0sZeZh2Q8u167onzEHVwMq1Cv-E5A@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] [Under Discussion] New Curl URL API
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=c3=bcsterhus?=)

Hi

On 6/24/22 15:49, Pierrick Charron wrote:
> 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 ?

I agree with Levi. The curl extension should be a thin wrapper over libcurl.

A high level API that is more convenient to use may be provided by PHP, 
but it should not be called curl. It should have a generic name with the 
fact that curl does the heavy lifting only being an implementation detail.

Best regards
Tim Düsterhus