[RFC][Vote] New Curl URL API

Sorry, I forgot to include the RFC Url :
https://wiki.php.net/rfc/curl-url-api

Le lun. 4 juill. 2022, à 19 h 34, Pierrick Charron pierrick@php.net a
écrit :

Hi internals,

I opened voting for the new Curl URL API as part of PHP8.2.

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.

The vote will last for 2 weeks and end on 19th of July.

Regards
Pierrick

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

Hi internals,

I opened voting for the new Curl URL API as part of PHP8.2.

I found some not clear fragments in the RFC.

const CURLUPART_USER = UNKNOWN; // what UNKNOWN?

"All errors of libcurl will become CurlUrlException."

"Setting a part to a null value will effectively remove that part's
contents", but the $content argument is of type string not ?string.

--
Aleksander Machniak
Kolab Groupware Developer [https://kolab.org]
Roundcube Webmail Developer [https://roundcube.net]

PGP: 19359DC1 # Blog: https://kolabian.wordpress.com

Clear "no" from me on this: this is something similar to a PSR-7 URI
object, but with a clunky and mutable API.

Something like this would/should go to packagist first, to assess adoption
there, but I would certainly not use it.

Hi internals,

I opened voting for the new Curl URL API as part of PHP8.2.

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.

The vote will last for 2 weeks and end on 19th of July.

Regards
Pierrick

Hi internals,

I opened voting for the new Curl URL API as part of PHP8.2.

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 fully support this approach: php-src is not the proper layer to build an
OOP API to me. Each time it's been done, it proved too rigid for userland
and ppl wrote wrappers around.

I think php-src should continue to provide thin layers on top of C
libraries so that userland is then empowered to build and evolve OOP APIs
at will.

Nicolas

I opened voting for the new Curl URL API as part of PHP8.2.
https://wiki.php.net/rfc/curl-url-api

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 agree with others that rushing to a vote is not the best way to handle
the situation here. We are now essentially voting on an RFC that has had
zero discussion time, since it has been completely rewritten.

I understand that you are keen to get this into a release because you
see it as a security feature, but that's exactly why we need to be sure
we have the right design.

I'm also still not clear who will use this API and how it will improve
their security. There seems to be a risk of people using these functions
in the wrong way, or the wrong circumstances, and actually making their
code less secure.

Because of all of the above, I have cast a No vote, because I would
rather the right implementation was delayed until PHP 8.3 than the wrong
implementation rushed into PHP 8.2.

Regards,

--
Rowan Tommins
[IMSoP]

Hi Internals,

The RFC has been declined with a vote of 10 in favor and 14 against.

Thank you for the votes.

Le lun. 4 juill. 2022, à 19 h 34, Pierrick Charron pierrick@php.net a
écrit :

Hi internals,

I opened voting for the new Curl URL API as part of PHP8.2.

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.

The vote will last for 2 weeks and end on 19th of July.

Regards
Pierrick