[RFC] [EPILOGUE] Server-Side Request and Response Objects (v2)

1 year ago by Paul M. Jones — view source

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.

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ł Brzuchalski
  • Peter Bowyer

• "SapiRequest should be mutable"

  • Niklas Keller
  • Johannes Schlüter

• "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üter
  • 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 $_SERVERwith 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=UTF-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.

--
Paul M. Jones
[email protected]
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