Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97552
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pthreads.org from 74.125.82.48 cause and error)
MIME-Version: 1.0
In-Reply-To: <D25FDAC5-A72F-4391-8414-8966124173ED@gmail.com>
References: <D25FDAC5-A72F-4391-8414-8966124173ED@gmail.com>
Date: Sat, 7 Jan 2017 12:00:47 +0000
Message-ID: <CAL=_i_mFfPNpPZ0z48LdoKwNt4DLRpBpZbVUoCyz8Bi2PA82zg@mail.gmail.com>
To: Paul Jones <pmjones88@gmail.com>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11444d44931f5505457fe2af
Subject: Re: [PHP-DEV] [RFC][Discussion] ServerRequest and ServerResponse objects
From: pthreads@pthreads.org (Joe Watkins)

--001a11444d44931f5505457fe2af
Content-Type: text/plain; charset=UTF-8

Morning Paul,

Regardless of the details of the implementation, I feel it necessary to
point out that this is a surprising RFC.

There are extensions that are absolutely a core part of the ecosystem that
remain outside of php-src because that is where they belong. xdebug is one,
apc was another, redis, memcached, and a whole list of others besides.

There's nothing whatever to gain (for us, or you, beyond short term goals
of exposure) in merging this extension into core:

  * it doesn't have any user base
  * would not benefit from our release schedule (indeed, it may be hindered
by it)
  * it is not restricted by what is possible outside of php-src (as phpdbg
was)

I'm afraid I just don't see the point. I think if you really want to push
this forward, the best place to do that is outside the core, where you can
pick a release schedule not bound by php-src, where the API can shift
because of the will of consumers, rather than internals (dis)ability to
agree on anything so contrived as how we should handle HTTP transactions.

The day may come where an abstraction is so popular that we should consider
merging it into core, dedicating our time to maintaining it, and even
possibly allow it to deprecate and completely replace the current API ...
it isn't now, and isn't this.

Cheers
Joe

On Fri, Jan 6, 2017 at 10:49 PM, Paul Jones <pmjones88@gmail.com> wrote:

> (This is a re-send, on a new thread, of the message originally posted at <
> http://news.php.net/php.internals/97461> with some minor edits. The
> original was apparently not delivered to the entire list.)
>
> ----------------------------------------
>
> Hi all,
>
> I have prepared an RFC on server-side request and response objects:
>
>   https://wiki.php.net/rfc/request_response
>
> This extension provides server-side request and response objects for PHP.
> These are not HTTP message objects proper. They are more like wrappers for
> existing global PHP variables and functions, with some limited additional
> convenience functionality.
>
> This extension defines two classes in the global namespace:
>
> - ServerRequest, composed of read-only copies of PHP superglobals and some
> other commonly-used values, with methods for adding application-specific
> request information in immutable fashion.
>
> - ServerResponse, essentially a wrapper around (and buffer for)
> response-related PHP functions, with some additional convenience methods,
> and self-sending capability.
>
> The extension is available as a PECL package for installation and testing
> at:
>
>   https://pecl.php.net/package/request
>
> Source and documentation are at:
>
>   https://gitlab.com/pmjones/ext-request
>
> I want to point out that I am not the author of the C code for this
> extension; John Boehr has done the work there, and I appreciate it a great
> deal.
>
> When I originally raised this topic in September, there were some
> questions left unanswered from Rowan Collins; I'll try to address them
> below.
>
> * * *
>
> Rowan asked why this would need to be implemented to as an extension or
> built into core: "Does it provide functionality that is hard to implement
> in a userland library?"
>
> It does. Among other things, making public read-only properties is
> difficult and hackish in userland. Making them remain read-only when a
> parent class is extended is (as far as I can tell) impossible. Both of
> those aspects figure prominently in ServerRequest.
>
> * * *
>
> Rowan also asked: "You mention that it is not just an HTTP wrapper, but
> although you mention researching other frameworks, I can't see any
> reference to PSR-7. What do you see as the relationship between your
> proposal and that standardisation effort?"
>
> While PSR-7 is not a framework, I get your point. ;-) For what it's worth,
> I was a sponsor on that proposal, so I'm relatively familiar with its
> history and purpose.
>
> I see the relationship as complementary. Those who want something that
> matches a formal HTTP model more closely can use one of the two popular
> PSR-7 implementations, or write their own.  Or they can use `pecl_http`,
> for that matter, which I think PSR-7 ends up mimicking in significant ways.
>
> Those who want something that more closely matches core PHP functionality,
> or the way-of-working presented by many extant frameworks and libraries,
> might find this extension more in line with their needs. I certainly do.
>
> * * *
>
> Finally, Rowan brought this up: "Why is [ServerRequest] property-only, but
> [ServerResponse] method-only? The asymmetry feels awkward to me."
>
> 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. The methods
> withUrl(), withInput(), and the various withParams() methods allow changing
> of immutable public properties on a clone of ServerRequest.
>
> (As a side note, immutability here is relatively strict. ServerRequest
> allows only null, scalar, and array values in these cases, and recursively
> checks that arrays themselves have only null, scalar, and array values.)
>
> * * *
>
> This (re-)opens the two-week discussion period, though I expect it may go
> on for longer than that.
>
> As this is a language change, a supermajority vote is needed to pass.
>
> Thanks in advance for your questions and criticism.
>
>
> --
> Paul M. Jones
> pmjones88@gmail.com
> 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
>
>

--001a11444d44931f5505457fe2af--