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!
