> 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.
