Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:96157
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.46 as permitted sender)
MIME-Version: 1.0
References: <DE0439B3-29F4-4BC6-B92A-A7630BE17196@gmail.com>
In-Reply-To: <DE0439B3-29F4-4BC6-B92A-A7630BE17196@gmail.com>
Date: Mon, 26 Sep 2016 21:10:49 +0000
Message-ID: <CANeXGWU67RKPvRdyLaigdTC+8d3H19Doph07fUuLrH_+W18quw@mail.gmail.com>
To: Paul Jones <pmjones88@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113d5d0e97b988053d6f900a
Subject: Re: [PHP-DEV] Server-Side Request/Response Objects
From: korvinszanto@gmail.com (Korvin Szanto)

--001a113d5d0e97b988053d6f900a
Content-Type: text/plain; charset=UTF-8

Hi Paul,
Thank you for spending the time to actually put this together!

I've been dipping my toes in the water asking around about this (sort of)
as well and feedback so far has been "That sounds great but I don't think
there is enough interest." So I'm very interested to see what kind of
response this gets here. Personally I would prefer complete HTTP message
objects similar to existing PSR-7 implementations be added perhaps
alongside these simple classes you've proposed.

Thanks,
Korvin

On Mon, Sep 26, 2016 at 12:38 PM 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
>
>

--001a113d5d0e97b988053d6f900a--