Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82502
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.178 as permitted sender)
MIME-Version: 1.0
Sender: rdlowrey@gmail.com
In-Reply-To: <54DBD4A9.8030402@php.net>
References: <CAH8MpnnLnUgbgWM0o8MO8=a0bP==cbLapXmpTmEqO2iZYSS1gQ@mail.gmail.com>
	<BD568277-5A74-4A66-AC5D-173DA93FA8FB@php.net>
	<CAH8MpnnOift5_zOk_XUP8iM2cxs80xQci8RspyqeWUNE+u9Vqw@mail.gmail.com>
	<54DBD4A9.8030402@php.net>
Date: Wed, 11 Feb 2015 18:26:29 -0500
Message-ID: <CAH8MpnkkQnyuVxuhCN0AqzsbfhCMB-oz32XKE_Uh5KkeG_Lr3w@mail.gmail.com>
To: Michael Wallner <mike@php.net>
Cc: Daniel Lowrey <rdlowrey@php.net>, "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113ed6543939bd050ed8553a
Subject: Re: [PHP-DEV] [RFC] [DISCUSSION] pecl_http
From: rdlowrey@php.net (Daniel Lowrey)

--001a113ed6543939bd050ed8553a
Content-Type: text/plain; charset=UTF-8

On Wed, Feb 11, 2015 at 5:16 PM, Michael Wallner <mike@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?

--001a113ed6543939bd050ed8553a--