Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109168
Message-ID: <5AF2B693-53C8-432E-89DC-E707232DF42C@benramsey.com>
Content-Type: multipart/signed;
	boundary="Apple-Mail=_234DF4A2-E590-481D-8460-461DF3C114E7";
	protocol="application/pgp-signature";
	micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
Date: Fri, 20 Mar 2020 12:02:10 -0500
In-Reply-To: <8B8A570A-545C-4CBF-9145-C9FC0B0E2AA1@pmjones.io>
Cc: PHP Internals <internals@lists.php.net>
To: "Paul M. Jones" <pmjones@pmjones.io>
References: <8B8A570A-545C-4CBF-9145-C9FC0B0E2AA1@pmjones.io>
Subject: Re: [PHP-DEV] [VOTE] Server-Side Request and Response Objects (v2)
From: ben@benramsey.com (Ben Ramsey)

--Apple-Mail=_234DF4A2-E590-481D-8460-461DF3C114E7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

> On Mar 20, 2020, at 08:31, Paul M. Jones <pmjones@pmjones.io> wrote:
>=20
> Hi all,
>=20
> I have opened the vote on Server-Side Request and Response Objects at =
<https://wiki.php.net/rfc/request_response>.
>=20
> The voting period will close two weeks from today on Fri 03 Apr 2020.


Paul,

I apologize for not speaking up more on the list during the discussion
phase. The one issue I did raise -- regarding the use of value objects
instead of arrays -- hits at one of the reasons why I=E2=80=99m voting =
=E2=80=9Cno=E2=80=9D on
this proposal. Others raised similar concerns on the list, which is why
it wasn=E2=80=99t necessary for me to jump in and restate the same =
concerns.

I appreciate the desire to keep this RFC small. Surely, it could grow
astronomically into a huge library with tons of classes and interfaces,
and being in core would be a detriment to it, since developers could
not iterate as quickly and users could not upgrade as often.

For this reason, I think this functionality is best provided by
userland libraries for now.

And now, a tangent=E2=80=A6

=46rom the RFC:

> PHP has lacked core server-side request and response objects for
> its entire existence

PHP hasn=E2=80=99t had these objects in core because of the way the =
SAPIs work.
In fact, I think the objects could be confusing because of this.
Python=E2=80=99s WSGI defines request and response objects for Python as =
a way
for the web application and the web server to communicate, while
remaining implementation-agnostic.

If PHP were to implement something of this sort, I think it should
explicitly adopt PSR-7 and PSR-15 interfaces and a modified form of
PEP-3333 (WSGI)[1] to work with the various SAPIs. In simplified terms,
one could specify a callable that the SAPI would invoke, passing it a
PSR-7 ServerRequestInterface object and PSR-15 RequestHandlerInterface
object.

It might look something like this:

    use Psr\Http\Message\ResponseInterface;
    use Psr\Http\Message\ServerRequestInterface;
    use Psr\Http\Server\RequestHandlerInterface;

    function application(
        ServerRequestInterface $request,
        RequestHandlerInterface $handler
    ): ResponseInterface {

        // Do stuff...

        $response =3D $handler->handle($request);

        // Do more stuff...

        return $response; // SAPI handles response object.
    }

    // Tell the SAPI what callable to invoke.
    ini_set('sapi.handler', 'application');

This is already an approach that many PHP frameworks have adopted, and
I think there is a lot of value in codifying this server communication
at the core, while remaining light on the definition of the objects,
and even allowing applications to provide and define their own
implementations.

As another pointed out, I think this will become more important as PHP
gets stronger support for long-running processes.

For now, I think this problem is best handled in userland.

Cheers,
Ben


[1]: https://www.python.org/dev/peps/pep-3333/


--Apple-Mail=_234DF4A2-E590-481D-8460-461DF3C114E7
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iHUEAREIAB0WIQToXQMR3fpbrPOmEOewLZeYnIwHGwUCXnT3EgAKCRCwLZeYnIwH
G+d3AP9HHW6i5bQ4WeqaX6MJIVQPmW3Bqdo3wvZOfpEwcW4qTgD/RkGRTgx1B22L
7BZawWmvJ0Nd1q4ghhaUUVagEvj3kG8=
=QHx9
-----END PGP SIGNATURE-----

--Apple-Mail=_234DF4A2-E590-481D-8460-461DF3C114E7--