Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78837
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.26 as permitted sender)
Content-Type: multipart/alternative; boundary="Apple-Mail=_ADB48D24-C0A3-4EFD-8708-574E3FFFDE26"
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
In-Reply-To: <CAL+t6cHSze7ojSu8SsF0gb11-x-fozYGxYbW95TJ+uSAv-KShw@mail.gmail.com>
Date: Fri, 7 Nov 2014 00:23:28 -0500
Cc: Andrea Faulds <ajf@ajf.me>,
 Stas Malyshev <smalyshev@sugarcrm.com>,
 Patrick ALLAERT <patrickallaert@php.net>,
 PHP Internals <internals@lists.php.net>
Message-ID: <00A54283-A64E-404A-AFF7-0D3DC5169C40@php.net>
References: <CAL+t6cGt8B+X4ptWbyo6zm_xoyBOJC4QeiH6DjCxHX11CPWm_g@mail.gmail.com> <CACwt+JcYMS=+3t3e_JLHbNx-mgxUceiPOws2GZn9_QZ4HEo4Uw@mail.gmail.com> <CAL+t6cHDLHjTE3JK0md=KZ=AnRns6iYxfphzA3qnShermVeOmg@mail.gmail.com> <1DDB6E05-3143-4A74-8B13-AF85222579BA@ajf.me> <CAL+t6cH92NgWnr-0gh9AfTxX_1r5Fd0=+M6SeZu53BT3nPHSEg@mail.gmail.com> <468730E8-4C38-49A3-A61A-59E107313D79@ajf.me> <CAL+t6cGPiqZXx2rQCzSV-PCzAAJtMWi6xteCU0GB0XjsB4wSpA@mail.gmail.com> <545C1823.8050404@sugarcrm.com> <D6194C8A-3375-4BA7-87C6-358A8247966E@ajf.me> <CAL+t6cHSze7ojSu8SsF0gb11-x-fozYGxYbW95TJ+uSAv-KShw@mail.gmail.com>
To: Sherif Ramadan <theanomaly.is@gmail.com>
Subject: Re: [PHP-DEV] New Standardized HTTP Interface
From: willfitch@php.net (Will Fitch)

--Apple-Mail=_ADB48D24-C0A3-4EFD-8708-574E3FFFDE26
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On Nov 7, 2014, at 12:16 AM, Sherif Ramadan <theanomaly.is@gmail.com> =
wrote:
>=20
> On Thu, Nov 6, 2014 at 7:56 PM, Andrea Faulds <ajf@ajf.me =
<mailto:ajf@ajf.me>> wrote:
>=20
>>=20
>>> On 7 Nov 2014, at 00:53, Stas Malyshev <smalyshev@sugarcrm.com> =
wrote:
>>>=20
>>> Hi!
>>>=20
>>>> Again, I think you're oversimplifying the problem. For one, you =
don't
>> know
>>>> that the payload is JSON unless you check the Content-type header
>> yourself,
>>>> and you really shouldn't have to since PHP could easily do this for =
you.
>>>=20
>>> Sure, PHP could easily do this, or any other one specific use case =
for
>>> you. What it can't do, however, is to do all 1000 use cases that =
modern
>>> REST application presents, automatically for you. What if you use =
XML
>>> and not JSON? What if you use both and determine which one it is by
>>> request URL suffix being .xml or .json? What if it instead is =
switched
>>> by query parameter? What if also it can be compressed, encrypted and
>>> wrapped in some MIME multipart message? Having all these =
complications
>>> handled in the core of PHP would be extremely hard, not because each =
of
>>> them is hard, but because there can be so many of them. And you'd =
run a
>>> big change of PHP still not matching your specific case exactly, or
>>> being behind times, because core can not evolve as quickly as =
userland
>>> does. That's why it's better done in extensions or user space - =
unless
>>> you can identify a case which covers a huge proportion of all cases =
-
>>> just like forms are for POST. For generic REST, I'm not sure there's
>>> such case, except for very generic API giving access to the basic
>>> request, its fields and supporting basic URL/MIME parsing.
>>=20
>> Even just parsing JSON isn=E2=80=99t as simple as it sounds. There =
are several
>> things users might like to configure, several ways to parse JSON =
(objects
>> vs. arrays, big numbers as floats or strings, etc.), while for =
form-data
>> there=E2=80=99s only one way.
>>=20
>=20
> Well, in this case it will be parsed as an array since $_POST is =
naturally
> parsed as an array. Also, since $_POST/$_GET are typically always =
processed
> as strings it would only make sense to use big numbers as strings in =
the
> JSON parsing as well. I don't think this is the big issue. The bigger =
issue
> is do users typically find the population of $_POST more useful than =
just
> reading the input stream themselves and handling the JSON payload on =
their
> own.

Sherif - I=E2=80=99m just going to be straight here. I haven=E2=80=99t =
seen support for your proposal at all in this thread.  You continue to =
try and make this case, but it continues to be shot down with absolutely =
valid issues, and your only responsive action is to argue back.  Why =
aren=E2=80=99t you considering alternatives?  Everything - and I do mean =
everything - that you want is available in pecl/http, and there=E2=80=99s =
already an RFC to get it into core.  Why can=E2=80=99t you get behind =
that and either support it, or move to propose an alternative that is =
supportable by at least someone.  Your current proposal is not supported =
by anyone in this thread, and you still can=E2=80=99t see that.

I admire and appreciate your efforts in making PHP better, but it=E2=80=99=
s time to go back to the drawing board on this proposal.  Everyone is =
against it, and I feel this thread=E2=80=99s patience is running thin.

>=20
>=20
>>=20
>> --
>> Andrea Faulds
>> http://ajf.me/ <http://ajf.me/>

--Apple-Mail=_ADB48D24-C0A3-4EFD-8708-574E3FFFDE26--