Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81417
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.171 as permitted sender)
MIME-Version: 1.0
Sender: julienpauli@gmail.com
In-Reply-To: <54C8D36E.7010803@php.net>
References: <54C8D36E.7010803@php.net>
Date: Fri, 30 Jan 2015 11:20:47 +0100
Message-ID: <CAMUwpuQ=ZSH076n5gwL8tyf2aaMfJCMBbvCvH_pk4jQbFib1yw@mail.gmail.com>
To: Michael Wallner <mike@php.net>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c342baaa6d38050ddbf744
Subject: Re: [PHP-DEV] [RFC] [VOTE] pecl_http
From: jpauli@php.net (Julien Pauli)

--001a11c342baaa6d38050ddbf744
Content-Type: text/plain; charset=UTF-8

On Wed, Jan 28, 2015 at 1:17 PM, Michael Wallner <mike@php.net> wrote:

> Hi,
>
> 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
>
>
Great debate in here. I did read all the answers and I agree with many.
My opinions summed-up :

- PHP is a web language, and if there is one thing that must be done right,
it's to provide a rich-efficient-easy-to-extend HTTP API to our users,
which with our actual stream wrappers, is not really the case.

- Why not use Curl ? I fully agree with Stas message here : Curl is the
open-source defacto library you bind against when you want to manage HTTP
messages (and many other layer-7 formats). Many many opensource projects
already binds it. Curl is rich, stable, opensource; cross platform,
efficient and supported by many companies. To answer Andrea : our HTTP
stream wrapper layer used to be able to use curl wrappers, we dropped such
a support in 5.6 AFAIR, because it was beeing experimental for years, and
nobody maintained this.
* In addition to that : Curl is actively working on the next HTTP2
standard. If we, PHP, were using it, we would immediately be compatible
with HTTP2 when it is released, without much effort.

- pecl_http is rich. I'm not saying I'd have vote +1 to it, but from the
very first start I used PHP, about 10y ago, I've always wondered why
pecl_http wasn't a core de-facto extension. Just try to play with HTTP
negociation or HTTP partial messages with vanilla PHP (without pecl_http)
and you'll see what PITA it is.  Look at Java interfaces (example :
https://tomcat.apache.org/tomcat-5.5-doc/servletapi/javax/servlet/http/package-summary.html),
they are not perfect, but they are clean, clear, OOP designed APIS. PHP
current HTTP API just makes me scared.

- And finally, probably the most important thing => I'm all +1 with Andrea
, saying that we have way too many places into PHP source code where HTTP
has been yet-once-again reimplemented. This is WRONG from a software
development POV. Easy as this. Have a look at ext/SAOP, at php-fpm, at PHP
streams .... So many duplicated code about handling HTTP. We suffer from
that (bug fixed in one place but not the other one). We absolutely need to
design a low level HTTP API at one unique place (ext/standard?) and reuse
it everywhere as well as provide userland access to it, like we've done for
so many dfferent things so far, but HTTP ....


Julien.Pauli

--001a11c342baaa6d38050ddbf744--