Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78537
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.46 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <B23AEFDD-AF47-4435-A882-F287B176EEA2@php.net>
References: <CAL+t6cGt8B+X4ptWbyo6zm_xoyBOJC4QeiH6DjCxHX11CPWm_g@mail.gmail.com>
	<5452B87B.5040009@garfieldtech.com>
	<CAL+t6cHqQL-TaurfG887qxeyeVZPCxQcnY_BrtD-oHCS196HQw@mail.gmail.com>
	<0B797CE3-7AFA-4330-9A98-D3CAFC6D6072@ajf.me>
	<CAL+t6cGanxv3dJONcECupw6Cfzup4s6At6tEcK_=Qagn67RNjw@mail.gmail.com>
	<5453B114.6050400@gmail.com>
	<CAL+t6cFCToJJGiCb8JhNe9oQws5UuBdKw+ot3rjUBQQr=7=Bxw@mail.gmail.com>
	<5453C250.8090803@gmail.com>
	<CAL+t6cEH7PPMu2G=e4NQau-iOznkG31-d187EMCDY0LFeew68g@mail.gmail.com>
	<CABRjmp-b1jGD1SBTxmnJFLKi++WbL4TBggijN+VfSjRjPMJYPQ@mail.gmail.com>
	<CAL+t6cF7t7shs78xSiBfGxZSCqh5zcU-B_WWjK5J9ebiB=PTQA@mail.gmail.com>
	<5453D6D5.2070705@garfieldtech.com>
	<CAL+t6cEyLFqQ9cRW3uiE-pRMsMEyOywAhWWDtg5zFFL-U2mogg@mail.gmail.com>
	<5453E492.6020304@gmail.com>
	<CAL+t6cE_vbjVhrgN6opoHrv1neSDCa4WZXs+BKoNTzvb80eknA@mail.gmail.com>
	<FB6607D7-5FCD-43FD-BF04-725451357C1B@php.net>
	<CAL+t6cFCOz3OgYYScoGYWvHQFFFjKEQHGghwgn23xFhYX9kk6g@mail.gmail.com>
	<B23AEFDD-AF47-4435-A882-F287B176EEA2@php.net>
Date: Fri, 31 Oct 2014 16:51:38 -0400
Message-ID: <CAL+t6cHO8C_=+UoG_oiaKwr4uymtCNDpz4YoqmGjT7SfpKbmaA@mail.gmail.com>
To: Will Fitch <willfitch@php.net>
Cc: Rowan Collins <rowan.collins@gmail.com>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7bd9201ad6df6b0506be292d
Subject: Re: [PHP-DEV] New Standardized HTTP Interface
From: theanomaly.is@gmail.com (Sherif Ramadan)

--047d7bd9201ad6df6b0506be292d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Oct 31, 2014 at 4:29 PM, Will Fitch <willfitch@php.net> wrote:

>
> On Oct 31, 2014, at 4:21 PM, Sherif Ramadan <theanomaly.is@gmail.com>
> wrote:
>
>
>
> On Fri, Oct 31, 2014 at 4:16 PM, Will Fitch <willfitch@php.net> wrote:
>
>>
>>
>>
>> While not too specific to Rowan, reiterating the pecl/http approach is
>> indirectly what your asking for? I have mentioned this numerous times, b=
ut
>> you haven=E2=80=99t responded with a reason not to take this approach - =
which is an
>> RFC that was presented for discussion prior to yours.
>
>
> I'm trying to understand how pecl/http solves the aforementioned problem
> any better? Again, I have no problem with competing ideas and it's not as
> though one is prohibited from presenting an idea for the mere fact that
> there exists a competing one. I'm just not seeing how pecl/http solves th=
e
> problem I intend to solve better. The reason I haven't responded to you y=
et
> is because I'm stilling weighing the two to try and make sense of whether
> or not these are in fact competing ideas or complimenting ones.
>
> Please, feel free to weigh in with anything that contradicts or concludes
> what I'm saying. I certainly don't expect to have all of the answers.
>
>
> What doesn=E2=80=99t pecl/http solve under your situation? The fact that=
=E2=80=99s it=E2=80=99s
> not directly integrated as part of ZE and handling process?
>


Well, you're the one suggesting an alternative. The onus is on you to prove
that it solves the same problem, not me. However, I'll bite for the
purposes of moving the discussion along...

As far as I understand, pecl/http attempts to solve a much larger scope of
problems than this RFC. Namely, dealing with HTTP messages in general,
whether they are a part of PHP's request/response model or not. i.e. there
is no direct integration of the PHP request into pecl/http and as such it
doesn't directly solve a problem such as properly parsing the HTTP request
body during a PUT request and properly populating the $_FILES/$_POST
superglobals. It also doesn't solve similar problems where a transport
message body is sent entirely in JSON to PHP and PHP is responsible for
handling.

Of course, yes, you can do accomplish this today with some hacks like using
the php://input stream, but it's only up until recently that this stream
has become reusable. It's also potentially creating some duplication, but
albeit this isn't the only problem.

This RFC also attempts to make it possible for users to directly apply
filters to input from the HTTP request so that they can simply retrieve the
fitlered data from the HttpRequest object directly without having to do
things like $foo =3D isset($_POST['foo']) ? filter_var($_POST['foo'],
FILTER_VAR_INT) : 0; // for example

I have nothing against pecl/http. I think it's a very useful library and
Mike seems to have put a great deal of work into it. I would gladly vote it
into PHP core. I'm just not clear on how it solves the same problems this
RFC attempts to solve. They can actually compliment each other in some
areas; I can see that.



>
> I certainly have no problem with competing ideas either. However, the onl=
y
> proposed patch in this RFC is a gist with PHP pseudocode.
>
>
>
>

It's not pseudocode since it's actually perfectly valid PHP code that will
compile and run in the PHP interpreter. However, it is intended to
demonstrate the behavior. The pecl/http RFC is also further along as it's
in discussion phase with an actual implementation. This RFC is merely a
draft, with no actual implementation proposed yet (but that's not at all
uncommon as many RFCs proposed in PHP did not provide an actual
implementation until after they were voted in: generators, list in foreach,
and finally are among a small number that come to mind). So let's not get
hung up on implementation being the barrier to entry for an RFC as that's
never ever been the case in the past.

It is, however, entirely understandable that the RFC should explain the
actual behavior and consequences as well as possible if it does not provide
an actual implementation. This is just a very early stage discussion to
gather ideas so that I can improve and finalize the RFC. I have not
actually placed the RFC into discussion or voting phase just yet. So let's
not put the cart before the horse.

--047d7bd9201ad6df6b0506be292d--