On Mon, Jul 21, 2025 at 10:47 AM Eric Norris wrote:
>
> On Mon, Jul 7, 2025 at 12:53 PM Eric Norris wrote:
> >
> > On Wed, Jul 2, 2025 at 11:48 AM Eric Norris wrote:
> > >
> > > > Based on the feedback so far (I do plan on waiting for more responses
> > > > to your email), and on my own preferen
On Mon, Jul 7, 2025 at 12:53 PM Eric Norris wrote:
>
> On Wed, Jul 2, 2025 at 11:48 AM Eric Norris wrote:
> >
> > > Based on the feedback so far (I do plan on waiting for more responses
> > > to your email), and on my own preferences, I wonder if there is a
> > > hybrid option I could propose. Pe
On Wed, Jul 2, 2025 at 11:48 AM Eric Norris wrote:
>
> > Based on the feedback so far (I do plan on waiting for more responses
> > to your email), and on my own preferences, I wonder if there is a
> > hybrid option I could propose. Perhaps the RFC could offer both a
> > \Curl\Handle (tentative nam
Hi all,
> On Jul 2, 2025, at 12:41, Larry Garfield wrote:
>
> On Wed, Jul 2, 2025, at 12:34 PM, Paul M. Jones wrote:
>> Hi all,
>>
>>> The question of PHP-native request/response objects has come up a couple of
>>> times, and even had an RFC that went to a vote (declined). My stance has
>>>
On Wed, Jul 2, 2025, at 12:34 PM, Paul M. Jones wrote:
> Hi all,
>
>> The question of PHP-native request/response objects has come up a couple of
>> times, and even had an RFC that went to a vote (declined). My stance has
>> been, and remains, that ... they should be powerful enough to effective
Hi all,
> The question of PHP-native request/response objects has come up a couple of
> times, and even had an RFC that went to a vote (declined). My stance has
> been, and remains, that ... they should be powerful enough to effectively
> replace/displace PSR-7.
Where and when have you previo
On Wed, Jul 2, 2025, at 10:48 AM, Eric Norris wrote:
> Having thought about this some more, while I'm still feeling somewhat
> positive about my suggestion I'm just not sure it's the best way to
> proceed. I started to sketch what a BasicHttpHandle class would look
> like, and I'm stuck on how to
On Wed, Jul 2, 2025, at 10:48 AM, Eric Norris wrote:
>> Based on the feedback so far (I do plan on waiting for more responses
>> to your email), and on my own preferences, I wonder if there is a
>> hybrid option I could propose. Perhaps the RFC could offer both a
>> \Curl\Handle (tentative name) to
> On Jul 2, 2025, at 10:48, Eric Norris wrote:
>
>> Based on the feedback so far (I do plan on waiting for more responses
>> to your email), and on my own preferences, I wonder if there is a
>> hybrid option I could propose. Perhaps the RFC could offer both a
>> \Curl\Handle (tentative name) to a
> Based on the feedback so far (I do plan on waiting for more responses
> to your email), and on my own preferences, I wonder if there is a
> hybrid option I could propose. Perhaps the RFC could offer both a
> \Curl\Handle (tentative name) to address position 1, and a
> \Curl\BasicHttpHandle (also
Thanks for your thoughtful response, Larry! I agree with your summary.
> 1. Status quo is fine. PHP core not having a user-friendly way to send HTTP
> requests is acceptable. Maybe make Curl a little nicer, but only to make life
> easier for Guzzle et al.
> 2. We should develop the Curl API unti
> I'm not even sure it's a good idea to add those namespaced options: using
> CURLOPT_SSL_VERIFYHOST is perfect to find the corresponding curl
> documentation with your favorite search engine. php's doc is awesome, but it
> cannot compete with the details provided by curl's doc on the topic.
Th
Thanks for your response Ayesh! I hope to see this RFC on php.watch :)
> However, I softly oppose this RFC in its current state and the way it
> seems to be going.
>
> I have pushed Curl and libcurl to some uncommon cases such as HTTP/3,
> DoH, the new debug callback (which I authored the PR for),
> More specifically, since it does introduce an entirely new namespace it
> should be considered a “new extension” and must therefore follow the
> Exception policy outlined in:
> https://github.com/php/policies/blob/main/coding-standards-and-naming.rst#throwables
Embarrassingly, I had read your RF
Hi
Am 2025-06-26 18:53, schrieb Larry Garfield:
2. Please don't name the exception "Exception". It needs some slightly
more useful name, to avoid confusion in a file that also uses
\Exception.
More specifically, since it does introduce an entirely new namespace it
should be considered a “ne
On Sat, 28 Jun 2025 at 08:03, Larry Garfield wrote:
> On Fri, Jun 27, 2025, at 4:58 PM, Ayesh Karunaratne wrote:
>
> > However, I softly oppose this RFC in its current state and the way it
> > seems to be going.
>
> So I think we've identified a key disagreement about not just the goal,
> but the
> On Jun 28, 2025, at 00:01, Larry Garfield wrote:
>
> On Fri, Jun 27, 2025, at 4:58 PM, Ayesh Karunaratne wrote:
>
>> However, I softly oppose this RFC in its current state and the way it
>> seems to be going.
>
> So I think we've identified a key disagreement about not just the goal, but
> t
On Fri, Jun 27, 2025, at 4:58 PM, Ayesh Karunaratne wrote:
> However, I softly oppose this RFC in its current state and the way it
> seems to be going.
So I think we've identified a key disagreement about not just the goal, but the
intent. To what extent should PHP core ship with a usable HTTP
> I'm not even sure it's a good idea to add those namespaced options: using
> CURLOPT_SSL_VERIFYHOST is perfect to find the corresponding curl
> documentation with your favorite search engine. php's doc is awesome, but it
> cannot compete with the details provided by curl's doc on the topic.
>
>
Le sam. 28 juin 2025 à 00:01, Ayesh Karunaratne a écrit :
> > Hello Internals,
> >
> > I'd like to formally propose a restart of the original object-oriented
> > curl API RFC (https://wiki.php.net/rfc/curl-oop):
> >
> > https://wiki.php.net/rfc/curl_oop_v2
> >
> > The prior RFC seemed to get posi
> Hello Internals,
>
> I'd like to formally propose a restart of the original object-oriented
> curl API RFC (https://wiki.php.net/rfc/curl-oop):
>
> https://wiki.php.net/rfc/curl_oop_v2
>
> The prior RFC seemed to get positive feedback, with a small consensus
> around wanting enum(s) for curl opti
Hi all,
> On 26/06/2025 18:21, Eric Norris wrote:
>> I know that in the prior discussion, Rowan Tommins had a vision for a
>> high-level API (https://externals.io/message/122371#122424)
>
>
> I think calling it a "vision for a high-level API" is making it sound far
> more grandiose than what I
-Original Message-
From: Eric Norris
Sent: Thursday, June 26, 2025 7:25 PM
To: PHP internals
Subject: [PHP-DEV] [RFC][DISCUSSION] Object-oriented curl API v2
> I'd like to formally propose a restart of the original object-oriented curl
> API RFC
Cool. Calling functions
On 27/06/2025 04:51, Eric Norris wrote:
I can try to take a look at the curl options and do some github
searches to see if I can identify common patterns. I agree that
setting the HTTP method and timeout are good contenders. If someone
else wants to propose a list as well, feel free!
For what
On 6/27/25 08:01, Deleu wrote:
With that said, for me this also threads into the bikeshedding area
that could spiral into a failed RFC. Be it a single Enum for
everything, constants, context-based enums or type-based enums, I
would much rather have this RFC than not have it. PHP is one of the
On Thu, Jun 26, 2025, at 10:51 PM, Eric Norris wrote:
>> Adding more helpers in later versions is entirely trivial, but we could
>> set the precedent with a first batch on day one.
>
> I'm not opposed to this, but I am - as previously stated - nervous
> about how and where we draw this line, since
On Fri, Jun 27, 2025, at 8:01 AM, Deleu wrote:
> On Fri, Jun 27, 2025 at 9:24 AM Jordi Boggiano wrote:
>> On 26.06.2025 18:25, Eric Norris wrote:
>> > - uses enumerations for curl options and other curl constants
>>
>> Overall I think the RFC is a good opportunity to clean up a few legacy
>> odd
On Fri, Jun 27, 2025 at 9:24 AM Jordi Boggiano wrote:
> On 26.06.2025 18:25, Eric Norris wrote:
> > - uses enumerations for curl options and other curl constants
>
> Overall I think the RFC is a good opportunity to clean up a few legacy
> oddities in the curl API, but I need to throw in my 2c abo
On 26.06.2025 18:25, Eric Norris wrote:
- uses enumerations for curl options and other curl constants
Overall I think the RFC is a good opportunity to clean up a few legacy
oddities in the curl API, but I need to throw in my 2c about enum usage
here, as someone that has actually implemented s
Thanks Rowan!
> I think calling it a "vision for a high-level API" is making it sound
> far more grandiose than what I suggested. What I suggested, and would
> still like to see, is a small number of additional methods, for setting
> really common options in a more user-friendly way.
I apologize
>
> On 26 Jun 2025, at 18:07, Rowan Tommins [IMSoP] wrote:
>
> On 26/06/2025 17:53, Larry Garfield wrote:
>
>> Now here's the big one: Using enums rather than a bunch of constants is a
>> good change. However, I feel like it doesn't go far enough.
>
>
> 100% this.
>
> Writing "$ch->setO
On 26/06/2025 17:53, Larry Garfield wrote:
Now here's the big one: Using enums rather than a bunch of constants is a good
change. However, I feel like it doesn't go far enough.
100% this.
Writing "$ch->setOptionInt(Curl\Option\IntOpt::ConnectTimeout, 30);"
instead of "curl_setopt(CURLOPT_
> Ben Ramsey hat am 26.06.2025 18:54 CEST geschrieben:
>
>
> On Thu, Jun 26, 2025 at 11:27 Eric Norris mailto:eric.t.nor...@gmail.com> wrote:
>
> > Hello Internals,
> >
> > I'd like to formally propose a restart of the original object-oriented
> > curl API RFC (https://wiki.php.net/rfc/c
Hello Internals,
I'd like to formally propose a restart of the original object-oriented
curl API RFC (https://wiki.php.net/rfc/curl-oop):
https://wiki.php.net/rfc/curl_oop_v2
The prior RFC seemed to get positive feedback, with a small consensus
around wanting enum(s) for curl options. I've taken
Thanks Larry!
> 1. I don't think the Curl\Option namespace is necessary. They can just be in
> the main Curl namespace.
I don't feel strongly here, but I thought it would be nice to group
the enums (if we go the multiple enum route) for discoverability.
Thoughts?
> 2. Please don't name the exc
> IMO, this sounds like something that would be great to start as a userland
> OOP wrapper for cURL, where it can be iterated on and the interface can be
> tested and changed much quicker. Then, maybe proceed to an external extension
> that can be migrated into core later, once its interface is
On Thu, Jun 26, 2025, at 11:25 AM, Eric Norris wrote:
> Hello Internals,
>
> I'd like to formally propose a restart of the original object-oriented
> curl API RFC (https://wiki.php.net/rfc/curl-oop):
>
> https://wiki.php.net/rfc/curl_oop_v2
>
> The prior RFC seemed to get positive feedback, with a
On Thu, Jun 26, 2025 at 11:27 Eric Norris wrote:
> Hello Internals,
>
> I'd like to formally propose a restart of the original object-oriented
> curl API RFC (https://wiki.php.net/rfc/curl-oop):
>
> https://wiki.php.net/rfc/curl_oop_v2
>
> The prior RFC seemed to get positive feedback, with a sma
38 matches
Mail list logo
