Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:108889 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 63979 invoked from network); 7 Mar 2020 18:06:22 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 7 Mar 2020 18:06:22 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 72A87180089 for ; Sat, 7 Mar 2020 08:26:33 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS29169 217.70.176.0/20 X-Spam-Virus: No X-Envelope-From: Received: from relay12.mail.gandi.net (relay12.mail.gandi.net [217.70.178.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sat, 7 Mar 2020 08:26:31 -0800 (PST) Received: from samurai.attlocal.net (107-223-28-39.lightspeed.nsvltn.sbcglobal.net [107.223.28.39]) (Authenticated sender: pmjones@pmjones.io) by relay12.mail.gandi.net (Postfix) with ESMTPSA id 8565C200002; Sat, 7 Mar 2020 16:26:28 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) In-Reply-To: Date: Sat, 7 Mar 2020 10:26:27 -0600 Cc: php internals Content-Transfer-Encoding: quoted-printable Message-ID: <31EDF305-712E-446E-A5EC-DA02753BC2AA@pmjones.io> References: <50BD013E-CF72-414C-BBC0-A7A2E45CBDDB@pmjones.io> <1657AB79-5CAF-4BCA-96B5-1343EC703CCD@pmjones.io> <3F9CFD7B-22AB-4284-8E23-94513ABB5C3F@pmjones.io> To: Rowan Tommins X-Mailer: Apple Mail (2.3608.60.0.2.5) Subject: Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2) From: pmjones@pmjones.io ("Paul M. Jones") Hi Rowan, > On Mar 4, 2020, at 17:13, Rowan Tommins = wrote: >=20 >> On 04/03/2020 20:01, Paul M. Jones wrote: >>=20 >> This RFC, in contrast, does not attempt to model HTTP messages. It = does not attempt to discard previous ways of working. Instead, it = proposes a more object-oriented representation of functionality that = already exists in PHP, honoring that previously-existing approach. There = is quite a bit of real-world experience as to how well it will work, = since it takes into account many commonalities between existing userland = projects. Thus, what the RFC purports to get close to is that existing = way-of-working, and I think it succeeds about as well as can be possible = for its goals. >=20 > This is something you have said a few times, and is definitely a = worthy goal, but it's not something that comes across very strongly in = the RFC itself. There is a comparison to Symfony HttpFoundation, but it = mentions as many differences as similarities; and there is a list of 13 = other implementations, but no information on how this proposal compares = to them. >=20 > I suspect that's just because you didn't want to burden the RFC with = too many details, but if you have any notes about what functionality is = common in existing libraries, perhaps that could be posted somewhere as = a kind of appendix to show where the current design came from? Your suspicion is correct; I thought the RFC was pretty long as it was. = And your suggestion is a good one; here is a Google Sheets doc of = summary findings (copied from my local spreadsheets): = https://docs.google.com/spreadsheets/d/e/2PACX-1vQzJP00bOAMYGSVQ8QIIJkXVdA= g-OMEfkgna7-b2IsuoWN8x_TazxEYn-yVDF2XQIqnzmHqdDO3KEKx/pubhtml When you see $foo, it means the feature is presented as a property, or = as a method on a public property object. When you see foo(), it means = the feature is presented as a public method on the object itself. Other notes: 1. On the Request and Response objects, I have a line for "nominal = public mode": - A nominal "readonly" is for the superglobal-derived public = properties. The object might include one or two mutable properties, but = those properties are application-specific, not superglobal-derived. = Gurther, the superglobal-derived properties might be mutable within a = protected scope but not a public one. - A nominal "mutable" means the superglobal-derived values are = mutable from public scope. - A nominal "immutable" means the object is intended to be immutable = (whether it succeeds or not). - Of the 14 projects, 8 have nominally readonly Request objects, and = all but one Response object are mutable. 2. Several projects retain "Forwarded" information internally on the = Request objects, but almost none of them expose it publicly. As it = appears to be an commonly-calculated set of values, I did include it in = ServerRequest, and made it available for public reading, so that = extenders/decorators can use it. 3. Likewise, several projects expose a "client IP" or "remote address" = value, but don't calculate it the same way. So even though it's a common = need, and I'd like to have it in ServerRequest, there's not broad = agreement on what that value ought to be. 4. Finally, several projects have some kind of Response cache methods, = usually in the form of setCache() etc., and then often with individual = cache directive methods. I recall that they differed in how they = retained the caching information; some wrote to headers directly, others = retained the directives individually and "compiled" them into a caching = header at sending time, etc. So while I would like to incorporate the = caching stuff into ServerResponse, I don't think there's enough = commonality between the implementations to warrant that. I hope the rest of it is self-explanatory, or easily-understood; if not, = let me know, and I'll answer your questions. And of course, if you = notice discrepancies or inaccuracies, tell me so I can correct them. --=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