Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108618
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
In-Reply-To: <fcf43463-f9f7-4235-a84b-658074772ed7@www.fastmail.com>
Date: Sun, 16 Feb 2020 06:49:00 -0500
Cc: php internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <5180E584-2613-4F36-BCAD-4DD047EBC818@newclarity.net>
References: <50BD013E-CF72-414C-BBC0-A7A2E45CBDDB@pmjones.io>
 <CANUQDCiP31aEqULqeGpN66ESHarKxWuXgQt_CqWeCLZc+1L-fA@mail.gmail.com>
 <5904137.fSVIMsojiJ@mcmic-probook>
 <CDBA02D0-07E1-4723-947C-22B403E650C0@pmjones.io>
 <CA+hqhpcOqCqXuOh3bWavJ+pZ5VVhekUO9LkKgd9c+b98VVnZSA@mail.gmail.com>
 <CAG9XoMRm2Nqjg3UbCc5=1_8m2W7qf8QRoSVk6d_qENJCKE1=9A@mail.gmail.com>
 <fcf43463-f9f7-4235-a84b-658074772ed7@www.fastmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Subject: Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
From: mike@newclarity.net (Mike Schinkel)

> On Feb 15, 2020, at 3:01 AM, Larry Garfield <larry@garfieldtech.com> =
wrote:
>=20
> Data point:
>=20
> In PSR-7, the names used are:
>=20
> - queryParams: The query string values.
> - parsedBody: The body of the message, converted to a meaningful =
value. If the request type is a form, then it MUST be equivalent to =
$_POST.  If not, it's up to the particular implementation to determine =
what "parsed" means.  (Eg, parsing a JSON body of a POST into some =
domain object, or whatever.)
> - The raw body is a stream called "body", or rather an OOP wrapper =
around a stream since PHP's native stream interface is fugly.
> - There's specific handling for uploadedFiles, too.
>=20
> cf: https://www.php-fig.org/psr/psr-7/
>=20
> To the earlier point about existing implementations, while there are a =
myriad of older, custom implementations of abstractions around =
superglobals, there's only two that are not decade-old proprietary =
implementations: HttpFoundation and PSR-7.  Those are, realistically, =
the only implementations that matter.  Anything else would be on the =
same order of magnitude effort to port to one of those as to port to =
this proposal.  In a meaningful sense, those are the only "existing =
competition".  Both also have robust ecosystems that make leveraging =
them in an entirely custom app pretty straightforward.
>=20
> (Whatever your feelings of the technical merits of either design, =
that's the current state-of-the-market.)
>=20
> Which therefore begs the question, is this proposal intended to =
supplant HttpFoundation and PSR-7, or to become a common underpinning =
that both of them wrap, or to be a third cohabitating implementation in =
the ecosystem?
>=20
> It doesn't seem robust enough to supplant both of them entirely, =
there's little value to either HttpFoundation or PSR-7 to rewrite their =
guts to wrap this object (though it's easier for PSR-7, as an interface, =
for someone to write a new implementation of it than for =
HttpFoundation), which would mean we'd end up with a 3rd in-the-wild =
implementation for user space to keep track of.
>=20
> I am unclear how that is a market win.

The win is it allows developer to provide a simple to use object =
oriented interface *in core*. IOW, without having to bring in an =
external PHP-code implementation that may or may not break in the =
future. =20

Another big win would be to allow developers to deprecate use of =
superglobals in their own apps.  However Paul do not want to add an ini =
setting to disable the use of superglobals.

But how could disabling superglobals be done in HttpFoundation or PSR-7? =
 Maybe Paul will reconsider adding such an capability to his RFC because =
it is something we cannot get with HttpFoundation and PSR-7.

Or maybe we should be looking at is a core implementation of PSR-7 =
instead; one that would allow us to disable access to the superglobals? =
One that people could subclass, of course. If we did that, we might hash =
out why some developers do not use PSR-7 and possibly fix its =
(perceived?) faults in a new PSR to amend PSR-7.

-Mike