Re: [RFC] [VOTE] pecl_http

From: Date: Wed, 28 Jan 2015 19:48:57 +0000
Subject: Re: [RFC] [VOTE] pecl_http
References: 1 2 3 4 5 6  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
On 28/01/15 20:18, Andrea Faulds wrote:
> Hi Michael,
> 
>> On 28 Jan 2015, at 19:13, Michael Wallner <[email protected]> wrote:
>> 
>> - Client
>> 
>> The http stream wrapper is a hack and the existing libcurl binding
>> is subpar. They could be improved separately, but that is not
>> subject of this RFC.
>> 
>> Currently only libcurl is implemented as a provider for the client 
>> functionality. Provides most of the functionality of current
>> libcurl. Representation of the request and response how a client
>> sees them. Support for parallel requests and optional libev{,ent}
>> support.
> 
> If the client is merely a wrapper around cURL, what benefit does it
> offer over ext/curl except a better API?
> 
> Personally, I’ve never liked that PHP requires cURL for doing HTTP
> requests. It’s a language made for the web, it should have built-in
> HTTP, and it should share code between its server-side HTTP and
> client-side HTTP stuff. I don’t think that the HTTP stream wrappers
> are a “hack” - they’re what PHP should have had all along. I think we
> should focus on improving them (so there’s no need to use cURL)
> rather than adding yet another HTTP client.

Sounds a bit like NIH.
We could implement a http_client driver with the code from the stream
wrapper and see how they compare in feature set and performance.

-- 
Regards,
Mike


Thread (53 messages)

« previous php.internals (#81328) next »