Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81318
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.200 as permitted sender)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
In-Reply-To: <CAFMT4NpjFSycCVrSUfBBgfJEJv=4Yw8cpmQ-45JWf=75ptr8Lg@mail.gmail.com>
Date: Wed, 28 Jan 2015 17:58:25 +0000
Cc: Michael Wallner <mike@php.net>,
 PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <4534A7F1-F7AB-4025-A9D0-5D82A482E836@ajf.me>
References: <54C8D36E.7010803@php.net> <CAFMT4NpjFSycCVrSUfBBgfJEJv=4Yw8cpmQ-45JWf=75ptr8Lg@mail.gmail.com>
To: Levi Morrison <levim@php.net>
Subject: Re: [PHP-DEV] [RFC] [VOTE] pecl_http
From: ajf@ajf.me (Andrea Faulds)

Hi Levi,

> On 28 Jan 2015, at 17:53, Levi Morrison <levim@php.net> wrote:
>=20
>>=20
>> 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.
>>=20
>> https://wiki.php.net/rfc/pecl_http#vote
>=20
>=20
> 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.
>=20
> 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.
>=20
> 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.

I completely agree here: reading the RFC I have little idea as to:

* What pecl/http actually is
* What pecl/http does
* How what pecl/http does differs from PHP=E2=80=99s existing facilities
* Why PHP should include pecl/http
* Why PHP should enable pecl/http by default

As it stands, I can=E2=80=99t see how it=E2=80=99s substantially =
different from our existing stuff in core, except maybe more OOP and a =
little more feature-complete. I=E2=80=99ve sort of gleaned this from =
looking at pecl/http=E2=80=99s docs=E2=80=A6 the RFC is barren, lacking =
in details about anything.

It really doesn=E2=80=99t make any case for itself, and I=E2=80=99m also =
concerned about possibly unnecessary implementation duplication. PHP =
already has several implementations of various aspects of the HTTP =
protocol, the RFC doesn=E2=80=99t explain why we need another.

So, like you, I=E2=80=99m probably going to vote No.

Thanks.

--
Andrea Faulds
http://ajf.me/