Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:97646 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 22604 invoked from network); 9 Jan 2017 22:33:40 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 9 Jan 2017 22:33:40 -0000 Authentication-Results: pb1.pair.com smtp.mail=rowan.collins@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=rowan.collins@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.45 as permitted sender) X-PHP-List-Original-Sender: rowan.collins@gmail.com X-Host-Fingerprint: 74.125.82.45 mail-wm0-f45.google.com Received: from [74.125.82.45] ([74.125.82.45:37627] helo=mail-wm0-f45.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id D0/83-31343-2CF04785 for ; Mon, 09 Jan 2017 17:33:40 -0500 Received: by mail-wm0-f45.google.com with SMTP id c206so50721874wme.0 for ; Mon, 09 Jan 2017 14:33:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=Q6tyIJKXUOHzF8a9J1hOjvZmPdOJ3t9X8em6Qt6VupU=; b=JTDvjE9w92KArQ1AO1o3ZTR2ytnEp4Vlgpi4QUKrEXfyC2keH5IHe6t5ZP9tqm2092 KkSbOKw8sUJMmLbbobxDt/gS7aRAfq01sjY6Ye7K38+p50E1UoHoBYgyqAsJ3yNviay9 fU8PIaTdXMW5nfl8spfQmotdkaiHZkYZ+E5cJ7fn6o/A8XywNp289yH95ceS1B6wDRNP k3K2SmWq3btZil8zxMJO9V7pAIHHu5OVlTUhuBqNqAoZYu6gYxYurFUlQ3FE1JdrQm1C WpOlF+fqSWBa3P5t1kaMVnN9TCsQgKNQky05bcu2Ikk2o6Ip3xpiQJC8YbkkyD+0u3sd 58Zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Q6tyIJKXUOHzF8a9J1hOjvZmPdOJ3t9X8em6Qt6VupU=; b=Tu/PJVgLlE+PN9Gq2BFdrB6dh+oHyvyGEj8P7l2g/8UoqOBr3NIVrgQxf6EyUHtZfQ dSb3zyKpsZlFQu6oh2oigjE8sXAotg8xhprl164hZq6n2bsdZLv9NTkJOWUNq+QoJj2s lUp2HCosVGTKEP07hE4erqeUntVIcskcphSFQ4VyU5Mu73V5d5MVF50MMu/cOB6l5oCA UJiDue+yE/biND+r6rOtHqmsAUL2KvIxbSslZKdGis4abTO7x+Fig2GIm+rIeLM1FEmA 4gMuaQDC1nmsbRPkaNzReNVNOm8717B3mKS5MQm8hcTFM0YSBj1fbJPtQX6UKLDyxOri +G7w== X-Gm-Message-State: AIkVDXKIVFAeMoaXrSb2PyMGcfCnKkkpDyqr2RHmsQkSx1K0rn39whOGrd1N4YzKAZCXpg== X-Received: by 10.28.163.3 with SMTP id m3mr241600wme.85.1484001215504; Mon, 09 Jan 2017 14:33:35 -0800 (PST) Received: from ?IPv6:2a00:23c4:4bd2:6e00:6100:e4a9:6fc3:6849? ([2a00:23c4:4bd2:6e00:6100:e4a9:6fc3:6849]) by smtp.googlemail.com with ESMTPSA id b3sm126100775wjy.40.2017.01.09.14.33.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Jan 2017 14:33:34 -0800 (PST) To: internals@lists.php.net References: <0D275F6F-85D3-4E9D-AF89-03C91A23D5BD@gmail.com> Message-ID: <14508079-3279-a638-4cbc-fcae01342ebc@gmail.com> Date: Mon, 9 Jan 2017 22:33:30 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC][Discussion] ServerRequest and ServerResponse objects From: rowan.collins@gmail.com (Rowan Collins) On 09/01/2017 15:43, Paul Jones wrote: > Either way, I think we can see from reactions here since then (and elsewhere) that there is some level of positive interest in the RFC as presented, as well as some healthy technical questioning. I'm happy to hear both. I think it's easy when you're proud of what you've got to feel like the point of discussion is to defend your proposal, and persuade others that it doesn't need to change; but at its best, it's about understanding how to refine and reshape your idea. So perhaps the surprise is less that you're going ahead with the proposal, and more with how little it's changed based on that initial feedback. In particular, the RFC still lacks an explanation of where this fits in the ecosystem alongside pecl_http and PSR-7, which aren't even mentioned once in the RFC, the extension's readme, or your blog post. > I get why that would be. It's really an outgrowth of the asymmetry that already exists in PHP: $_GET, $_POST, et al. are properties representing the request, whereas header(), setcookie(), et al. are all functions for sending a response. > > Having said that, practical use of ServerRequest the intervening time has given rise to some methods for application-related convenience. This all seems rather arbitrary to me. You're creating a new API, presumably because you feel the existing way of accessing these things is inadequate; yet you take as your starting point being as close to the legacy APIs as possible. Then you add some genuinely new functionality, but without any stated goal or philosophy regarding what should be added and what left out. The most important thing, though, is that you don't need an RFC to pass for people to start using this - you've already listed it on PECL, so if you think it's ready, and has a use case, you can mark it final, and people can start using it right away. The bar for inclusion in core is necessarily higher, and comes at a cost to you as well - you lose control of when the code is released, and even what direction future development will take. I think there is the germ of a useful project in here, but if you want it to become the official PHP answer to some question, you need to think more about what that question is, and how to make it the very best answer. Regards, -- Rowan Collins [IMSoP]