Thanks for your thoughtful response, Larry! I agree with your summary. > 1. Status quo is fine. PHP core not having a user-friendly way to send HTTP > requests is acceptable. Maybe make Curl a little nicer, but only to make life > easier for Guzzle et al. > 2. We should develop the Curl API until it's usable for basic HTTP behavior, > but no further. > 3. We should bundle an HTTP client that wraps Curl (with or without minor > improvements to Curl), exact scope TBD. > > Personally, I'm open to either 2 or 3. 3 is more bikesheddable, but possibly > the better end result. > > Where does everyone else stand?
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.
