Re: [PHP-DEV] [RFC] [EPILOGUE] Server-Side Request and Response Objects (v2)

[Paul M. Jones]

> On Apr 9, 2020, at 02:29, Côme Chilliet  
> wrote:
> 
> Le mercredi 8 avril 2020, 07:35:10 CEST Paul M. Jones a écrit :
> 
>> **Lesson:** Of functionality that can be accomplished in userland, only 
>> trivial/simple functionality is acceptable.
> 
> My take on that is more that functionality in core needs to be «perfect», or 
> at least near unanimous. And of course it’s way easier to find a solution 
> which pleases everyone when it’s for something quite simple.

Ah, yes, that latter sentence makes for a a subtle difference, and I think a 
fair one. Nicely said.


-- 
Paul M. Jones
pmjo...@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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [EPILOGUE] Server-Side Request and Response Objects (v2)

[Côme Chilliet]

Le mercredi 8 avril 2020, 07:35:10 CEST Paul M. Jones a écrit :
> ## 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.

My take on that is more that functionality in core needs to be «perfect», or at 
least near unanimous. And of course it’s way easier to find a solution which 
pleases everyone when it’s for something quite simple.
I do think OO interface for request/response in core is something that could 
pass, but it would need to be more in line with what people want/expect.

> ### 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.

You clearly disagree on this with most participants in the discussion, but 
saying «this RFC is not a challenge» is not enough to make it true, there was a 
clear overlap of feature between your RFC and existing userland projects so it 
made sense to compare them.

-- 
Côme Chilliet
FusionDirectory - https://www.fusiondirectory.org

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[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 .

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 .

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-of-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ł 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. . An RFC for this exists at 
; perhaps it should be 
revivified before PHP 8 goes out the door.

- Rowan Tommins had several suggestions in 
:

- "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=UTF-8`." This kind of thing is 
achievable in userland, so the "no userland functonality" objection would 
appear to apply; however, it is