On Wed, Feb 11, 2015 at 5:16 PM, Michael Wallner <m...@php.net> wrote: > > On 06/02/15 17:44, Daniel Lowrey wrote: > > If you doubt that this is a solved problem in userland consider the > > performance of my own 100% userland HTTP client demonstrated here > > without the use of curl or any other extensions: > > > > https://gist.github.com/rdlowrey/54171625334670ccb9f5 > > I can replicate about 2.5s with artax/master on http://example.org, > which is about the same pace like pecl_http. With pipelining enabled > pecl_http/master peeks at about 0.7s, but what's the point? > > PS: I'm on an advertised 150/15 Mbit connection. > > -- > Regards, > Mike
The point isn't *zomg this one thing I did in userland is super fast.* It's irrelevant. The point here is that HTTP transfers are an IO-bound operation and as such the benefit from compiling them is relatively small. Add that to the fact that we already have tools to do exactly this in the standard distribution (curl) and well-known, well-tested userland tools for any use-case you can imagine. In my opinion that adds up to not needing another way to do the same thing in the standard distribution. Who benefits from bundling another HTTP client? Why bring in two additional pecl dependencies for HTTP connections which *rarely* make sense to persist across web SAPI requests? Is there a plan to also deprecate ext/curl? These are questions that aren't resolved in a satisfactory way as far as I'm concerned. I honestly don't care that much, I just don't think "because we can" necessarily means "we should" when there's no obvious need for more of the same overlapping functionality. That's what pecl is for, right?