Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:96158
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.178 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CADyq6s+rtq7L9KAwka=cnPh4ihBMZqO6h_yLiDMoZcaOe8AAQw@mail.gmail.com>
References: <DE0439B3-29F4-4BC6-B92A-A7630BE17196@gmail.com>
 <CADyq6s+sygYe5ZoadV2f+RubcsoK7b-+5OU1kLhrJVV452vK4A@mail.gmail.com> <CADyq6s+rtq7L9KAwka=cnPh4ihBMZqO6h_yLiDMoZcaOe8AAQw@mail.gmail.com>
Date: Mon, 26 Sep 2016 23:19:50 +0200
Message-ID: <CADyq6sLBPpDtOf7NJiBzORSmc_TU_GfkCJEwkwWf2ZTg_FcxPA@mail.gmail.com>
To: Paul Jones <pmjones88@gmail.com>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e011770953f0791053d6fb0ac
Subject: Re: [PHP-DEV] Server-Side Request/Response Objects
From: ocramius@gmail.com (Marco Pivetta)

--089e011770953f0791053d6fb0ac
Content-Type: text/plain; charset=UTF-8

Hey Paul,

On 26 Sep 2016 21:38, "Paul Jones" <pmjones88@gmail.com> wrote:
>
> Hi all,
>
> tl;dr: Gauging interest in an extension for server-side PHP request and
response objects (*not* HTTP messages per se; see below) prior to writing
an RFC for them on the wiki.
>
> * * *
>
> From time to time we've all heard the complaint that PHP has no built-in
request object to represent the execution environment. Userland ends up
writing these themselves, and those are usually tied to a specific library
collection or framework. The same is true for a response object, to handle
the output going back to the web client. I've written them myself more than
once, as have others here.
>
> After doing some library and framework research (linked later) it looks
like there is a reasonably  common subset of request/response functionality
across all the userland implementations. That functionality also appears
useful to non-framework users.
>
> I wrote up a userland implementation for that limited subset of
functionality, and John Boehr then used that as a reference point for the C
version. It is PHP 7.x only, and you can see the result at:
>
>   <https://gitlab.com/pmjones/phprequest>
>
> (The userland reference implementation is at <
https://gitlab.com/pmjones/phprequest/tree/master/refimpl>, and the
research subjects are in <
https://gitlab.com/pmjones/phprequest/tree/master/refimpl/notes>.)
>
> The extension provides server-side request and response objects for PHP.
They are *not* HTTP message objects proper. They are more like wrappers for
existing global PHP variables and functions, with some limited additional
convenience functionality. There are only two classes:
>
> - StdRequest, essentially a read-only struct composed of PHP superglobals
and some other commonly-used values
>
> - StdResponse, essentially a wrapper around (and buffer for)
response-related PHP functions, with some additional convenience methods,
and self-sending capability
>
> I thought this might best be offered as a PECL extension first, leading
(I would hope) to becoming a part of the PHP distribution later if it
proves out.  However, PECL has not responded in the past few days (perhaps
I have not waited long enough).
>
> In the mean time, I am bringing it up here to either (1) get PECL's
attention, or (2) begin the RFC process if there's enough interest per <
https://wiki.php.net/rfc/howto>.
>
> I'm happy to answer any questions, and undergo any criticism, that you
may have regarding this. Thanks for your time and attention.
>
>
> --
>
> Paul M. Jones
> http://paul-m-jones.com
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

After all the effort put into getting PSR-7 working (and now adopted, which
seems to be happening quite quickly), and the previous
Symfony\HttpFoundation, having yet another API seems like three step s
backwards to me.

--089e011770953f0791053d6fb0ac--