Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118187
Return-Path: <marandall@php.net>
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 73736 invoked from network); 4 Jul 2022 22:17:52 -0000
Received: from unknown (HELO localhost.localdomain) (76.75.200.58)
  by pb1.pair.com with SMTP; 4 Jul 2022 22:17:52 -0000
To: internals@lists.php.net
Date: Tue, 5 Jul 2022 01:10:28 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.10.0
Content-Language: en-GB
References: <CAOfKkdR0cab4-rWdVpzGPtg8nraNBWLN3whe9xs2mAw5x1MVyw@mail.gmail.com>
In-Reply-To: <CAOfKkdR0cab4-rWdVpzGPtg8nraNBWLN3whe9xs2mAw5x1MVyw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Posted-By: 149.241.131.223
Subject: Re: [RFC][Vote] New Curl URL API
From: marandall@php.net (Mark Randall)
Message-ID: <php.internals-118187@news.php.net>

On 05/07/2022 00:34, Pierrick Charron wrote:
> All recent discussions show that we are not even close to getting a
> consensus on how the new CurlUrl OO API should be done. After changing my
> mind 300 times in the last day, I decided to only propose the procedural
> implementation that stays consistent with other functions of the ext/curl
> to target 8.2. I know this is not the ideal scenario, but with 8.2 feature
> freeze in two weeks, this is I think the only approach that will not put us
> in a potentially bad/harmful situation for a better future with ext/curl.


I'm voting no on this one based on the discussions from R11.

The deadline being close is not a good enough reason to rush a change 
like this that will be difficult to unwind later.

I agree with some of the other comments made that it would be preferable 
to come up with a more generic solution that can be used by multiple 
components rather than something specific to Curl.

Mark Randall