Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109162
Return-Path: <marandall@php.net>
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 8233 invoked from network); 20 Mar 2020 16:12:01 -0000
Received: from unknown (HELO localhost.localdomain) (76.75.200.58)
  by pb1.pair.com with SMTP; 20 Mar 2020 16:12:01 -0000
To: internals@lists.php.net
References: <8B8A570A-545C-4CBF-9145-C9FC0B0E2AA1@pmjones.io>
Date: Fri, 20 Mar 2020 14:35:27 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <8B8A570A-545C-4CBF-9145-C9FC0B0E2AA1@pmjones.io>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-Posted-By: 87.81.129.66
Subject: Re: [VOTE] Server-Side Request and Response Objects (v2)
From: marandall@php.net (Mark Randall)
Message-ID: <php.internals-109162@news.php.net>

On 20/03/2020 13:31, Paul M. Jones wrote:
> I have opened the vote on Server-Side Request and Response Objects at <https://wiki.php.net/rfc/request_response>.
To practice what I preach:

I have voted against, as I don't believe this proposal offers anything 
which isn't already possible using much more comprehensive and 
well-supported userland libraries.

At best, adding in yet another mechanism risks further fragmenting the 
ecosystem to the major detriment of ecosystem interoperability.

This RFC should be revisited if PHP ever gets native support for 
long-running multi-request processes, as at that time there would be a 
clear need for a self-contained request-specific request / response object.

Mark Randall