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.

Reply via email to