Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82055
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.169 as permitted sender)
MIME-Version: 1.0
Sender: rdlowrey@gmail.com
In-Reply-To: <BD568277-5A74-4A66-AC5D-173DA93FA8FB@php.net>
References: <CAH8MpnnLnUgbgWM0o8MO8=a0bP==cbLapXmpTmEqO2iZYSS1gQ@mail.gmail.com>
	<BD568277-5A74-4A66-AC5D-173DA93FA8FB@php.net>
Date: Fri, 6 Feb 2015 11:44:35 -0500
Message-ID: <CAH8MpnnOift5_zOk_XUP8iM2cxs80xQci8RspyqeWUNE+u9Vqw@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=001a113edac4c2d6f9050e6e22d6
Subject: Re: [PHP-DEV] [RFC] [DISCUSSION] pecl_http
From: rdlowrey@php.net (Daniel Lowrey)

--001a113edac4c2d6f9050e6e22d6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

>> I=E2=80=99ve rewritten the RFC for pecl_http and hopefully addressed mos=
t of the
>> things mentioned previously.
>>
>> I you still find anything lacking, please let me know, so I can expand
the
>> RFC accordingly.
>>
>> And of course, everything else is up for discussion.
>>

I may not have been clear before, but just to be sure ...

I would really like to see the pecl/http RFC broken up into multiple voting
options instead of one giant "yes" or "no" as per my previously mentioned
concerns:

> 1. There is a lot of *really* useful functionality in pecl/http that IMO
should be bundled with the standard PHP distribution.
> 2. There is some functionality here that isn't HTTP-specific and should
exist in other extensions.
> 3. There is some functionality here that IMO belongs in pecl/ and not ext=
/
> 4. There is some functionality here that will likely upset some people
because it's subjective

I also want to reiterate my feeling that PHP *does not* need to bundle yet
another HTTP client -- especially one that brings other pecl dependencies
with it. There's just no reason for doing this (other than API waffling).
Performance is not a valid reason (we have ext/curl, which is fine if you
want something that's compiled). Also, when you consider that HTTP resource
traversal is more than adequately handled in userland already this addition
just doesn't make a ton of sense to me. Let's bring the things that
actually benefit from being compiled into the standard distribution; the
rest should stay in pecl.

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

If this proposal is "all or nothing" then I have to vote "no" ... and it
would be a shame to miss out on the beneficial portions of pecl/http :(

--001a113edac4c2d6f9050e6e22d6--