> 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


Attachment: signature.asc
Description: Message signed with OpenPGP

Reply via email to