Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78538
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 66.111.4.27 as permitted sender)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
In-Reply-To: <CAL+t6cHO8C_=+UoG_oiaKwr4uymtCNDpz4YoqmGjT7SfpKbmaA@mail.gmail.com>
Date: Fri, 31 Oct 2014 17:01:15 -0400
Cc: Rowan Collins <rowan.collins@gmail.com>,
 PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <41EF28AA-2303-4900-A085-21AF58740351@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>
 <CAL+t6cHO8C_=+UoG_oiaKwr4uymtCNDpz4YoqmGjT7SfpKbmaA@mail.gmail.com>
To: Sherif Ramadan <theanomaly.is@gmail.com>
Subject: Re: [PHP-DEV] New Standardized HTTP Interface
From: willfitch@php.net (Will Fitch)


> On Oct 31, 2014, at 4:51 PM, Sherif Ramadan <theanomaly.is@gmail.com> =
wrote:
>=20
> On Fri, Oct 31, 2014 at 4:29 PM, Will Fitch <willfitch@php.net> wrote:
>=20
>>=20
>> On Oct 31, 2014, at 4:21 PM, Sherif Ramadan <theanomaly.is@gmail.com>
>> wrote:
>>=20
>>=20
>>=20
>> On Fri, Oct 31, 2014 at 4:16 PM, Will Fitch <willfitch@php.net> =
wrote:
>>=20
>>>=20
>>>=20
>>>=20
>>> While not too specific to Rowan, reiterating the pecl/http approach =
is
>>> indirectly what your asking for? I have mentioned this numerous =
times, but
>>> 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.
>>=20
>>=20
>> 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 the
>> problem I intend to solve better. The reason I haven't responded to =
you yet
>> 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.
>>=20
>> 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.
>>=20
>>=20
>> 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?
>>=20
>=20
>=20
> 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=E2=80=A6

I=E2=80=99m actually not suggesting an alternative - I=E2=80=99m =
suggesting this RFC isn=E2=80=99t an option.

>=20
> 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.

Sure, pecl/http solves a much larger scope of problems related to HTTP, =
but that does not mean it can=E2=80=99t serve the purpose you=E2=80=99re =
trying to accomplish.  If your attempt is to force everyone into an =
approach using the defined interfaces/classes in the RFC, this is going =
nowhere.  First of all, you=E2=80=99re assuming PHP is an OOP-only =
language. =20

>=20
> 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.

You don=E2=80=99t need to tie into the input stream - use pecl/http...

>=20
> 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 understand why you=E2=80=99d want this in specific use-cases, but =
don=E2=80=99t tie everyone to your needs. This isn=E2=80=99t a =
requirement for a language.  Plenty of frameworks can provide exactly =
what you=E2=80=99re describing.

>=20
> 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.
>=20
>=20
>=20
>>=20
>> I certainly have no problem with competing ideas either. However, the =
only
>> proposed patch in this RFC is a gist with PHP pseudocode.
>>=20
>>=20
>>=20
>>=20
>=20
> 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.

My apologies.  Please replace pseudocode with prototypes.

>=20
> 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.

I=E2=80=9Dm not suggesting you provide a patch, and I=E2=80=99m actually =
glad you didn=E2=80=99t do the work yet. =20