Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109563
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
Message-ID: <C1004135-2052-49C6-8016-EA655B7F5B94@pmjones.io>
Date: Wed, 8 Apr 2020 07:35:10 -0500
Cc: bishop@php.net,
 ajf@ajf.me,
 Rowan Tommins <rowan.collins@gmail.com>
To: PHP Internals <internals@lists.php.net>
Subject: [RFC] [EPILOGUE] Server-Side Request and Response Objects (v2)
From: pmjones@pmjones.io ("Paul M. Jones")

Hi all,

First, the voters-in-favor will be pleased to find that I have released =
the request extension (v2) via PECL at <https://pecl.php.net/request>.

Second, I will be contacting the documentation team under separate cover =
to begin getting the ext/request documentation into the php.net manual; =
the current documentation exists at =
<https://github.com/pmjones/ext-request>.

Finally, in the spirit of [Publish Your Failures][], the remainder of =
this message is an after-action/lessons-learned regarding the declined =
RFC. Skip to the end for a list of potential RFC candidates.

  [Publish Your Failures]: =
http://paul-m-jones.com/post/2013/10/28/publish-your-failures-or-the-way-o=
f-all-frameworks/

Again, and as ever, thanks to everyone who provided useful feedback on =
this RFC.

* * *

## Summary of Objections

The non-technical objections had more overlap among voters than the =
technical ones, and some voters brought them up only at voting time. No =
non-technical objections were raised at voting time.

### Technical Objections

- "SapiRequest is not OO enough"

    - Ben Ramsey
    - Rowan Tommins
    - Peter Bowyer

- "SapiRequest properties seem arbitrary"

    - Micha=C5=82 Brzuchalski
    - Peter Bowyer

- "SapiRequest should be mutable"

    - Niklas Keller
    - Johannes Schl=C3=BCter

- "SapiRequest readonly is a hack"

    - Dan Ackroyd

- "SapiRequest: how to tell $files from $uploads?"

    - Rowan Tommins

- "SapiRequest should hold superglobal references rather than copies"

    - Peter Bowyer

### Non-Technical Objections

- "Leave request/response objects to userland"

    - Mark Randall
    - Johannes Schl=C3=BCter
    - Niklas Keller
    - Ekin Bayar
    - Marco Pivetta (at vote)
    - Ben Ramsey (at vote)

- "Disruptive to (or insufficiently unifiying of) userland ecosystem"

    - Mark Randall
    - Larry Garfield
    - Marco Pivetta (at vote)
    - Ekin Bayar (at vote)

- "BC breaking changes could only happen on major versions"

    - Dan Ackroyd

## Lessons Learned

### Userland Functionality

The initial impression is that there is a strong desire for work that =
*can* be done in userland to *stay* in userland. However, that =
impression conflicts with the recent acceptance of `str_contains()`, =
which is very easily done in userland.

**Lesson:** Of functionality that can be accomplished in userland, only =
trivial/simple functionality is acceptable.

### Userland Ecosystem

There was somewhat less concern for "the ecosystem," but it too was =
prevalent in the discussion.

**Lesson:** Perceived challenges to popular userland projects are going =
to be met with strong resistance by their existing stakeholders, even =
when an RFC is explicitly not a challenge to them.

### Design Orthodoxy

The technical objections were almost entirely centered around =
SapiRequest, to the near-exclusion of substantial objections regarding =
SapiResponse and SapiResponseSender.

**Lesson:** Even when an RFC purports to bring together and rationalize =
common approaches from different projects, deviations from orthodox =
design in one part of it (however reasonable for its context) will be =
met with strong resistance, to the detriment of the whole RFC.

### Participation

7 of 9 voters in favor (not including the RFC authors themselves) =
expressed no support during the discussion; i.e., 77% did not =
participate before voting.

24 of 35 voters against expressed no objections during the discussion; =
i.e., 70% did not participate when voting, even after being explicitly =
asked to do so.

In total, 31 of 44 voters did not participate in the discussion; i.e., =
about 70% did not participate before voting.

**Lesson:** If those percentages hold for other RFC conversations, it =
means that future RFC proposers might presume that each participating =
voter represents about 3 (+/-) non-participating voters.

## Followup RFCs

The discussion revealed the following possible RFC candidates.

- Andrea Faulds mentioned that it would be nice to fix the name mangling =
scheme. <https://externals.io/message/97461#97465>. An RFC for this =
exists at <https://wiki.php.net/rfc/on_demand_name_mangling>; perhaps it =
should be revivified before PHP 8 goes out the door.

- Rowan Tommins had several suggestions in =
<https://externals.io/message/108436#108627>:

    - "A more reliable way to get the URL the user requested than =
checking 5 different variables in `$_SERVER`." Is it possible to =
populate `$_SERVER`with a new key, where the value is the full URL =
string, including scheme/authority/path/etc?

    - "A way to parse data in multipart/form-data format decoupled from =
the current HTTP request". Is it possible to extract & expose PHP's =
internnal multipart/form-data parsing mechanism?

    - "Tools for working with Content-Type strings, such as a function =
for correctly parsing things like `text/html;charset=3DUTF-8`." This =
kind of thing is achievable in userland, so the "no userland =
functonality" objection would appear to apply; however, it is =
comparatively trivial, so might get around that object on those grounds.

- There was a general sentiment that rewriting/rethinking the =
superglobals and global response functionality would be worthwhile, but =
also that it is a huge undertaking, and would require several years to =
put in place responsibly.

* * *

--=20
Paul M. Jones
pmjones@pmjones.io
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php