Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81317
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.181 as permitted sender)
MIME-Version: 1.0
Sender: morrison.levi@gmail.com
In-Reply-To: <CAFMT4NpjFSycCVrSUfBBgfJEJv=4Yw8cpmQ-45JWf=75ptr8Lg@mail.gmail.com>
References: <54C8D36E.7010803@php.net>
	<CAFMT4NpjFSycCVrSUfBBgfJEJv=4Yw8cpmQ-45JWf=75ptr8Lg@mail.gmail.com>
Date: Wed, 28 Jan 2015 10:58:10 -0700
Message-ID: <CAFMT4NqUU21HGuOf1qZiHP8MvzG4q=o8G99UN5ushLZLh3ydtg@mail.gmail.com>
To: Michael Wallner <mike@php.net>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113b7e9c571739050dba1de7
Subject: Re: [PHP-DEV] [RFC] [VOTE] pecl_http
From: levim@php.net (Levi Morrison)

--001a113b7e9c571739050dba1de7
Content-Type: text/plain; charset=UTF-8

On Wed, Jan 28, 2015 at 10:53 AM, Levi Morrison <levim@php.net> wrote:

> Discussion has been very low on this topic since it was proposed on
>> August 19th, so I just opened the vote on the RFC whether to add
>> pecl_http to the core. The vote will be open until about 12:00 UTC on
>> Friday, February 6th.
>>
>> https://wiki.php.net/rfc/pecl_http#vote
>
>
> I wish you had pinged the list before opening the vote. I know there were
> a few people who wanted to make comments but have just been very busy. For
> example, I have been dealing with the return types RFC which has soaked up
> all of the time I have for working on PHP projects.
>
> Some feedback: I feel the RFC is not clear about the advantages and
> disadvantages of including this package. Mostly, the RFC is "hey I have
> this package can we include it in core?" I feel like it's fairly incomplete
> as to *why* we should include it. There is a fair amount of work done in
> user-land for these types of utilities, and I think without a more balanced
> discussion we'd be giving this extension a distinct advantage.
>
> If we allow it to remain in voting phase despite these issues, I have to
> vote no simply because I don't feel like there is enough information
> presented in the RFC for anyone except current pecl_http users to make a
> good decision; that's hardly a good situation for the language as a whole.
>
>
Oh, one more item: has anyone had time to review the pieces and how they
all interact, as well as reviewing the quality of each component? I should
hardly think in the time given this has been done. I'm not saying this
extension is bad; I am saying that I don't think there's been time for
anyone to properly evaluate whether it is or not.

--001a113b7e9c571739050dba1de7--