On Mon, Jul 21, 2025 at 10:47 AM Eric Norris <eric.t.nor...@gmail.com> wrote: > > On Mon, Jul 7, 2025 at 12:53 PM Eric Norris <eric.t.nor...@gmail.com> wrote: > > > > On Wed, Jul 2, 2025 at 11:48 AM Eric Norris <eric.t.nor...@gmail.com> 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 address position 1, and a > > > > \Curl\BasicHttpHandle (also tentative name) that addresses position 2? > > > > If people were amenable, I'd even make the BasicHttpHandle a separate > > > > vote. > > > > > > > > I agree that 3 is both more bikesheddable and also possibly ideal, but > > > > I feel my above suggestion maybe strikes the right balance between the > > > > "status quo is fine, I don't want to see random HTTP-related methods > > > > on my low(est)-level curl object" and the "I'd like to do basic HTTP > > > > stuff with curl, without a library" crowds. > > > > > > > > Barring that, my preference would be 2, but I'd accept 1 just to have > > > > it pass - like I mentioned elsewhere, I think there is value in > > > > introducing namespaces and object-oriented APIs for "modernization" > > > > and language consistency reasons. > > > > > > 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 get data about the response out of the > > > class. > > > > > > Naively, we could have $response_status_code and $response_headers > > > properties, and have the same fetch() and execute() methods I > > > suggested elsewhere to get the response body. Alternatively, we could > > > return a simple CurlHttpResponse object which contains all three > > > properties in the fetch() and execute() implementations for the > > > BasicHttpHandle class. > > > > > > Both of these are fine, but they would lock us out of being PSR7 > > > compatible. I think that people would probably desire PSR7 > > > compatibility, and I would feel uncomfortable with eliminating or > > > tainting the possibility of achieving this. For example, if we had > > > this BasicHttpHandle and then later introduced PSR7 response objects, > > > we'd need to either break backwards compatibility for the class, or > > > introduce a second class. We could also go straight to returning a > > > PSR7 compatible response for the BasicHttpHandle class, but I think > > > that likely deserves its own RFC. > > > > > > So in closing, if people felt generally okay with the limitation of > > > not being PSR7 compatible, I'd probably still add some form of my > > > BasicHttpHandle suggestion as a secondary vote. If people thought PSR7 > > > was necessary, I'd drop it, and leave a PSR7-in-core RFC for the > > > future. In that case, I'd go with Larry's option 1 for the RFC; I've > > > currently updated the RFC to match that option for now. > > > > Thanks Ben, Larry, and Paul for your responses to my suggestion for a > > BasicHttpHandle class. After reflecting further, I have decided to > > move this to the Future Scope section, as it feels weighty enough to > > stand as its own RFC. I'd like to think about this a bit more, but I > > will note that having a Request and Response interface in core would > > greatly simplify the proposal for a simple curl-based HTTP client, so > > I'd likely support any effort on that front. > > > > I've also updated the Curl\MultiHandle class proposal to account for > > removing the CURLOPT_RETURNTRANSFER option. > > > > At this point I believe the RFC is in a semi-final state at this > > point, barring any additional discussion. Thanks all for the feedback > > so far! > > I'd like to bring this to a vote since discussion has died down, but I > feel that I should implement the proposal before doing so. As always > this is the hard part, and since I'm back from an extended break at > work I will have less time to focus on this. > > I've mentioned this before, but if anyone would like to collaborate on > the implementation, please reach out! Otherwise, I'll update this > thread with a link to the implementation at some point in the future, > give it a little more time for discussion, and bring the proposal to a > vote.
Apologies, quick clarification: I do not intend to target PHP 8.5, and will update the RFC to note this.
