Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108591
User-Agent: Cyrus-JMAP/3.1.7-802-g7a41c81-fmstable-20200203v1
Mime-Version: 1.0
Message-ID: <fcf43463-f9f7-4235-a84b-658074772ed7@www.fastmail.com>
In-Reply-To: 
 <CAG9XoMRm2Nqjg3UbCc5=1_8m2W7qf8QRoSVk6d_qENJCKE1=9A@mail.gmail.com>
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>
Date: Sat, 15 Feb 2020 02:01:59 -0600
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
From: larry@garfieldtech.com ("Larry Garfield")

On Fri, Feb 14, 2020, at 10:47 AM, Benjamin Morel wrote:
> >
> > What about $query and $body? That would be closer to the terminology=

> > used in HTTP RFCs.
>=20
>=20
>=20
> The problem is that $body is typically used to get the raw message bod=
y as
> a string or stream.
> I was thinking more something along the lines of $bodyParams, which is=
 more
> verbose but leaves no ambiguity: *$queryParams* and *$bodyParams*.
>=20
> =E2=80=94 Benjamin

Data point:

In PSR-7, the names used are:

- 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 aroun=
d a stream since PHP's native stream interface is fugly.
- There's specific handling for uploadedFiles, too.

cf: https://www.php-fig.org/psr/psr-7/

To the earlier point about existing implementations, while there are a m=
yriad of older, custom implementations of abstractions around supergloba=
ls, there's only two that are not decade-old proprietary implementations=
: HttpFoundation and PSR-7.  Those are, realistically, the only implemen=
tations that matter.  Anything else would be on the same order of magnit=
ude effort to port to one of those as to port to this proposal.  In a me=
aningful sense, those are the only "existing competition".  Both also ha=
ve robust ecosystems that make leveraging them in an entirely custom app=
 pretty straightforward.

(Whatever your feelings of the technical merits of either design, that's=
 the current state-of-the-market.)

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 ecosys=
tem?

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 so=
meone to write a new implementation of it than for HttpFoundation), whic=
h would mean we'd end up with a 3rd in-the-wild implementation for user =
space to keep track of.

I am unclear how that is a market win.

PDO was mentioned previously as a model.  Yes, there were many user-spac=
e implementations prior to PDO.  PDO effectively supplanted and obsolete=
d them.  However... PDO was also never thought-through enough or robust =
enough to be used directly, spawning a whole new ecosystem of PDO++ libr=
aries that people actually use (Doctrine, Eloquent, Drupal's DBTNG, Aura=
.sql, to name but a few).  So, not the full win people were hoping for. =
 If that pattern holds, we'd end up with... a new generation of this-RFC=
++ wrappers that still abstract it away yet aren't compatible with each =
other.

That said, PDO did have the advantage of at least partially unifying dis=
parate SQL APIs.  There really aren't multiple incompatible HTTPs to abs=
tract over the way there is for SQL backends, so the analogy is somewhat=
 weak either way.

--Larry Garfield