> On Mar 20, 2020, at 08:31, Paul M. Jones <pmjo...@pmjones.io> wrote: > > Hi all, > > I have opened the vote on Server-Side Request and Response Objects at > <https://wiki.php.net/rfc/request_response>. > > 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’m voting “no” on
this proposal. Others raised similar concerns on the list, which is why
it wasn’t 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…
From the RFC:
> PHP has lacked core server-side request and response objects for
> its entire existence
PHP hasn’t 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’s 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 = $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/
signature.asc
Description: Message signed with OpenPGP
