> On Jul 2, 2025, at 10:48, 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.
I think it’s good to keep PSR-7 in mind when designing the interface, but I don’t think it’s necessary to strive for 100% compatibility. Userland will end up writing wrappers for it that implement PSR-7. IMO, the interface should attempt to more closely follow curl nomenclature and idioms, since it’s an interface for interacting with curl. Cheers, Ben
signature.asc
Description: Message signed with OpenPGP
