Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78532
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.49 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <5453E492.6020304@gmail.com>
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>
Date: Fri, 31 Oct 2014 16:05:42 -0400
Message-ID: <CAL+t6cE_vbjVhrgN6opoHrv1neSDCa4WZXs+BKoNTzvb80eknA@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e01228626889def0506bd85c6
Subject: Re: [PHP-DEV] New Standardized HTTP Interface
From: theanomaly.is@gmail.com (Sherif Ramadan)

--089e01228626889def0506bd85c6
Content-Type: text/plain; charset=UTF-8

On Fri, Oct 31, 2014 at 3:35 PM, Rowan Collins <rowan.collins@gmail.com>
wrote:

> Sherif Ramadan wrote on 31/10/2014 18:52:
>
>> This RFC is about core PHP and I really don't care how
>> many competing ideas exist out there that are closely or mildly related to
>> this RFC.
>>
>
> The decision about *whether this is needed in core* is not something you
> can ignore by saying "this is about core". The fact that PHP-FIG is working
> on something very closely related to this makes a difference to that
> question, and pretending that's irrelevant is not constructive.
>
>
First of all, I'm not ignoring anything. I very much appreciate all of your
input. However, reiterating what you've already said with every single one
of your responses attempting to derail this discussion into a matter that
concerns FIG or PSR or whatever other third party concern that is
tangentially related to the word HTTP is something I will not stand for.

I read what you've had to say about FIG and PSR and I'm taking it into
consideration. That doesn't mean I have to yield to your preference. Nor
does that mean this RFC has now become irrelevant because somewhere on
planet earth someone has come up with a competing idea/concept. I welcome
competition. That is only beneficial to PHP.

If you would like to further this discussion beyond reiterating the words
PSR and FIG then please explain to me how what you're talking about solves
any of the problems I'm attempting to solve with this RFC? Namely, how does
this PSR solve the problem that PHP will not populate $_FILES or $_POST if
a multipart PUT request is sent to PHP? Pointing out specifics, using
references, and providing any additional examples/documentation is more
than welcome if it will help me improve this RFC (but only if it is geared
toward the same goals that this RFC has).

Thanks

--089e01228626889def0506bd85c6--