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.
