Welcome! Log In Create A New Profile

Advanced

[PHP-DEV] [RFC][Discussion] ServerRequest and ServerResponse objects

Posted by Paul Jones 
(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
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
>
>
Hi all,

Replying to both Marco Pivetta and Joe Watkins here, as some of their critiques overlap. I apologize in advance for the length of this email.

* * *

On Jan 6, 2017, at 10:47, Marco Pivetta <ocramius@gmail.com> wrote:

> Bundling the [PSR-7] interface is no biggie, so I suggest steering away and going that way

It's a bigger deal than one might think. But again, I have no desire to highlight the negatives of PSR-7 in this discussion.

I'd much rather discuss the RFC on its own merits, which Marco does next:

> There are several technical issues too:
>
> * A magic constructor that fetches data from global state: add a factory for that, leave the constructor open for modifications or new instantiation ways, or make it private.

I get that. John and I tried both variations, and found that the static-factory version was clunkier than we expected. For example, if ServerRequest uses a static factory, then users extending the ServerRequest class will additionally have to write their own factory. Having the constructor just "felt" better when we used it. But, I am willing to revisit that decision if needed.

As far as global state: yeah, I hear you. Since ServerRequest is intended to encapsulate the superglobals, it seemed reasonable to have it default to copying the superglobals internally. Note that the `__contruct(array $globals = [])` signature allows for a complete override of whatever you want. (The vagaries of JIT population come into play here as well.)


> * Magic read-only properties that go against the language semantics: make 'em accessors, or do whatever you want, but don't invent new language semantics just for your own extension.

You're right that it's not often seen. However, public read-only properties are not a new invention for this RFC. They already exist, such as in PDOStatement::$queryString https://secure.php.net/pdostatement.

FWIW, the use of a public read-only property turns out to be very practical in daily work. Instead of variations on ...

$request->getPost(); // returns the whole array
$request->getPost($key); // returns a value in the array
$request->getPost($key)[$subkey]; // returns a sub-value in the array
$request->getPost($key, $default); // returns a value, or a default if not present

.... you work with the property like any other array:

$request->post;
$request->post[$key];
$request->post[$key][$sub];
$request->post[$key] ?? $default;

It's just that the property is read-only, and you get an exception if you try to change it (same as with PDOStatement::$queryString, if I recall correctly.)



> * A series of non-exhaustive properties that give some "helper" API to see if it's XHR or not, violating basic SRP. Are you abstracting a request or what you want to do with the request? You can define separate utility functions for that. Yes, functions.

/me nods

They are definitely non-exhaustive; the list of properties was put together from several reference projects that have classes similar to ServerRequest (more on that below).

When some of those projects had a use for for a particular value, I figured it made sense to include it here. (If you or others want to provide patches to make it more exhaustive, so much the better!)

As for being a violation of the single-responsibility principle, I don't know. It seems reasonable to think that if the object contains (e.g.) `$request->server['HTTP_FORWARDED']`, it might do well to contain a parsed version of the same information as an array in `$request->forwarded`.


> * As per current API, I'd expect the ctor to throw an exception when used outside the web SAPI context

I will defer to John Boehr on this one. I do wonder how difficult that would make it to test at the command-line, or include in command-line testing environments (e.g. PHPUnit).


> * You use the *with* prefix for setting values, while you know exactly that *with* was used to differentiate from a mutable and a non-mutable API in the existing request abstractions: this makes things confusing again

I'm sorry, I don't understand the criticism here. The `ServerRequest::with*()` methods do in fact provide an immutable API (a pretty strict one at that). That is, they return a new copy of the ServerRequest object with the changed values, leaving the original copy unchanged. Maybe I'm not getting what you're saying ... ?


> * There's no interface for these classes, and they are not marked as final, as far as I can see. This means that users will extend them (unwise choice), and with that they will have a class with reflection bits in the extension (extremely bad idea!). An interface and final are needed here.

Extensibility is an intended option. Many classes in PHP can be extended, to good effect (e.g., PDO). But I am willing to be hear about why this is a bad call -- can you expand on your reasoning?

> I am obviously defensive and biased here

Sure; anyone would be. Thanks for being up-front about it though. :-)

* * *

On Jan 7, 2017, at 06:00, Joe Watkins <pthreads@pthreads.org> wrote:
>
> Regardless of the details of the implementation, I feel it necessary to point out that this is a surprising RFC.

My apologies for giving you cause to be surprised. I thought I had broadcast my intentions back in September http://news.php.net/php.internals/96156 but obviously I failed. My bad.


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

Noted. Honestly I figure at best this extension has only 1 chance in 3 of getting accepted.

However, as I think it is central to the operation of PHP in its primary use cases (i.e., reading superglobals and sending back response headers/cookies/content), taking that chance seems worthwhile.


> * it is not restricted by what is possible outside of php-src (as phpdbg was)

FWIW, I have not found it possible to provide read-only public properties in userland, especially when extending a parent class that wants to enforce the read-only nature of those properties. This is central to the intent of ServerRequest.

Further, as far as I know, it is not possible to detect if a variable is a reference in userland. Doing so is a prerequsite to enforcing immutability, which ServerRequest intends to do.

I am of course happy to be corrected on this, as it would solve other problems I have had elsewhere.

* * *

Both Joe and Marco had a similar observation.

Marco said:

> if something new is being designed for inclusion in php-src, and it has to reach millions of developers, it better be *reeeeeealli* good. .... IMO needs another few design iterations, and a lot more adoption, in order to become interesting. Orrrrr you provide us with a factory for an implementation of these concepts that already has adoption, traction and extremely careful design behind it.

Joe said:

>
> * it doesn't have any user base
>
> ...
>
> 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 ...

You are both completely correct, of course, that this extension has so little adoption as to be virtually unknown. It is, in itself, a infant.

However, its design is born from commonalities across many different projects, from many different authors. They all independently settled on broadly similar solutions to the problem of dealing with PHP superglobals, and PHP global functions for sending response elements, in a more OO-ish way.

Links to references, and longer explanation of the "broadly similar solutions" are in my blog post at http://paul-m-jones.com/archives/6494. Meanwhile, note that the reference projects include Aura, Cake, Code Igniter, Horde, Joomla, Lithium, MediaWiki, Phalcon, Symfony (and thereby Drupal and Laravel), Yaf, Yii, and Zend Framework. That's a mere dozen that are themselves representative of wide swaths of other parts of PHP userland.

So it is true that this extension, per se, is not widely adopted. But it is also true the collection of ideas and solutions it represents is widely vetted and broadly agreed-upon in intent, if not in the names of specific classes, methods, and properties.


--
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
Evening Paul,

> My apologies for giving you cause to be surprised. I thought I had
broadcast my intentions back in September <http://news.php.net/php.
internals/96156> but obviously I failed. My bad.

The point of an internals discussion is to gather consensus that an RFC is
a good idea; let us look at the responses you got:

* Marco said it felt like three steps backwards
* Micheal said he felt it was covered by http extension
* Larry said he didn't see that this adds value
* Rowan said it was an interesting idea, but didn't see how it fitted
into the wider ecosystem
* Davey agreed with Rowan and went on to question how it could fit in
with HTTP/2.0

That doesn't sound like a positive consensus that this is a good idea, it
is rather the opposite.

Hopefully you can see now why I am surprised that you are deciding to push
forward with something that didn't get any positive responses, and only got
a few people talking.

> FWIW, I have not found it possible to provide read-only public properties
in userland

To be clear, I didn't suggest that you write in PHP, I just stated that
this does not belong in the core.

> However, its design is born from commonalities across many different
projects, from many different authors. They all independently settled on
broadly similar solutions to the problem of dealing with PHP superglobals,
and PHP global functions for sending response elements, in a more OO-ish
way.

Of course those projects have commonalities, they are all solving the same
"problem", for the same purpose, using the same internal API ... I'm not
sure what point you are trying to make here, and "OO-ish" doesn't mean
anything.

I'll end how I started: The point of these discussions is to gather
consensus, and a consensus has emerged that this is not the right solution,
nor the right time, nor the right implementation, nor the right route.

Please think about that.

Cheers
Joe

On Sat, Jan 7, 2017 at 9:12 PM, Paul Jones <pmjones88@gmail.com> wrote:

> Hi all,
>
> Replying to both Marco Pivetta and Joe Watkins here, as some of their
> critiques overlap. I apologize in advance for the length of this email.
>
> * * *
>
> On Jan 6, 2017, at 10:47, Marco Pivetta <ocramius@gmail.com> wrote:
>
> > Bundling the [PSR-7] interface is no biggie, so I suggest steering away
> and going that way
>
> It's a bigger deal than one might think. But again, I have no desire to
> highlight the negatives of PSR-7 in this discussion.
>
> I'd much rather discuss the RFC on its own merits, which Marco does next:
>
> > There are several technical issues too:
> >
> > * A magic constructor that fetches data from global state: add a
> factory for that, leave the constructor open for modifications or new
> instantiation ways, or make it private.
>
> I get that. John and I tried both variations, and found that the
> static-factory version was clunkier than we expected. For example, if
> ServerRequest uses a static factory, then users extending the ServerRequest
> class will additionally have to write their own factory. Having the
> constructor just "felt" better when we used it. But, I am willing to
> revisit that decision if needed.
>
> As far as global state: yeah, I hear you. Since ServerRequest is intended
> to encapsulate the superglobals, it seemed reasonable to have it default to
> copying the superglobals internally. Note that the `__contruct(array
> $globals = [])` signature allows for a complete override of whatever you
> want. (The vagaries of JIT population come into play here as well.)
>
>
> > * Magic read-only properties that go against the language semantics:
> make 'em accessors, or do whatever you want, but don't invent new language
> semantics just for your own extension.
>
> You're right that it's not often seen. However, public read-only
> properties are not a new invention for this RFC. They already exist, such
> as in PDOStatement::$queryString https://secure.php.net/pdostatement.
>
> FWIW, the use of a public read-only property turns out to be very
> practical in daily work. Instead of variations on ...
>
> $request->getPost(); // returns the whole array
> $request->getPost($key); // returns a value in the array
> $request->getPost($key)[$subkey]; // returns a sub-value in the array
> $request->getPost($key, $default); // returns a value, or a default if
> not present
>
> ... you work with the property like any other array:
>
> $request->post;
> $request->post[$key];
> $request->post[$key][$sub];
> $request->post[$key] ?? $default;
>
> It's just that the property is read-only, and you get an exception if you
> try to change it (same as with PDOStatement::$queryString, if I recall
> correctly.)
>
>
>
> > * A series of non-exhaustive properties that give some "helper" API to
> see if it's XHR or not, violating basic SRP. Are you abstracting a request
> or what you want to do with the request? You can define separate utility
> functions for that. Yes, functions.
>
> /me nods
>
> They are definitely non-exhaustive; the list of properties was put
> together from several reference projects that have classes similar to
> ServerRequest (more on that below).
>
> When some of those projects had a use for for a particular value, I
> figured it made sense to include it here. (If you or others want to provide
> patches to make it more exhaustive, so much the better!)
>
> As for being a violation of the single-responsibility principle, I don't
> know. It seems reasonable to think that if the object contains (e.g.)
> `$request->server['HTTP_FORWARDED']`, it might do well to contain a
> parsed version of the same information as an array in `$request->forwarded`.
>
>
> > * As per current API, I'd expect the ctor to throw an exception when
> used outside the web SAPI context
>
> I will defer to John Boehr on this one. I do wonder how difficult that
> would make it to test at the command-line, or include in command-line
> testing environments (e.g. PHPUnit).
>
>
> > * You use the *with* prefix for setting values, while you know exactly
> that *with* was used to differentiate from a mutable and a non-mutable API
> in the existing request abstractions: this makes things confusing again
>
> I'm sorry, I don't understand the criticism here. The
> `ServerRequest::with*()` methods do in fact provide an immutable API (a
> pretty strict one at that). That is, they return a new copy of the
> ServerRequest object with the changed values, leaving the original copy
> unchanged. Maybe I'm not getting what you're saying ... ?
>
>
> > * There's no interface for these classes, and they are not marked as
> final, as far as I can see. This means that users will extend them (unwise
> choice), and with that they will have a class with reflection bits in the
> extension (extremely bad idea!). An interface and final are needed here.
>
> Extensibility is an intended option. Many classes in PHP can be extended,
> to good effect (e.g., PDO). But I am willing to be hear about why this is
> a bad call -- can you expand on your reasoning?
>
> > I am obviously defensive and biased here
>
> Sure; anyone would be. Thanks for being up-front about it though. :-)
>
> * * *
>
> On Jan 7, 2017, at 06:00, Joe Watkins <pthreads@pthreads.org> wrote:
> >
> > Regardless of the details of the implementation, I feel it necessary to
> point out that this is a surprising RFC.
>
> My apologies for giving you cause to be surprised. I thought I had
> broadcast my intentions back in September <http://news.php.net/php.
> internals/96156> but obviously I failed. My bad.
>
>
> > 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.
>
> Noted. Honestly I figure at best this extension has only 1 chance in 3 of
> getting accepted.
>
> However, as I think it is central to the operation of PHP in its primary
> use cases (i.e., reading superglobals and sending back response
> headers/cookies/content), taking that chance seems worthwhile.
>
>
> > * it is not restricted by what is possible outside of php-src (as
> phpdbg was)
>
> FWIW, I have not found it possible to provide read-only public properties
> in userland, especially when extending a parent class that wants to enforce
> the read-only nature of those properties. This is central to the intent of
> ServerRequest.
>
> Further, as far as I know, it is not possible to detect if a variable is a
> reference in userland. Doing so is a prerequsite to enforcing immutability,
> which ServerRequest intends to do.
>
> I am of course happy to be corrected on this, as it would solve other
> problems I have had elsewhere.
>
> * * *
>
> Both Joe and Marco had a similar observation.
>
> Marco said:
>
> > if something new is being designed for inclusion in php-src, and it has
> to reach millions of developers, it better be *reeeeeealli* good. ... IMO
> needs another few design iterations, and a lot more adoption, in order to
> become interesting. Orrrrr you provide us with a factory for an
> implementation of these concepts that already has adoption, traction and
> extremely careful design behind it.
>
> Joe said:
>
> >
> > * it doesn't have any user base
> >
> > ...
> >
> > 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
> ...
>
> You are both completely correct, of course, that this extension has so
> little adoption as to be virtually unknown. It is, in itself, a infant.
>
> However, its design is born from commonalities across many different
> projects, from many different authors. They all independently settled on
> broadly similar solutions to the problem of dealing with PHP superglobals,
> and PHP global functions for sending response elements, in a more OO-ish
> way.
>
> Links to references, and longer explanation of the "broadly similar
> solutions" are in my blog post at http://paul-m-jones.com/archives/6494.
> Meanwhile, note that the reference projects include Aura, Cake, Code
> Igniter, Horde, Joomla, Lithium, MediaWiki, Phalcon, Symfony (and thereby
> Drupal and Laravel), Yaf, Yii, and Zend Framework. That's a mere dozen that
> are themselves representative of wide swaths of other parts of PHP userland.
>
> So it is true that this extension, per se, is not widely adopted. But it
> is also true the collection of ideas and solutions it represents is widely
> vetted and broadly agreed-upon in intent, if not in the names of specific
> classes, methods, and properties.
>
>
> --
> 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
>
>
> On Jan 7, 2017, at 15:41, Joe Watkins <pthreads@pthreads.org> wrote:
>
> That doesn't sound like a positive consensus that this is a good idea, it is rather the opposite.

Not to get into interpretations of comments, but while I agree that there were one or two actual negatives, they were predicated on a misunderstanding of the purpose of the RFC. As such I took them as neutral, rather than negative. The remainder were questions or comments, and not negative ones.

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.


--
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
On Mon, Jan 9, 2017 at 10:43 AM, Paul Jones <pmjones88@gmail.com> wrote:

>
> > On Jan 7, 2017, at 15:41, Joe Watkins <pthreads@pthreads.org> wrote:
> >
> > That doesn't sound like a positive consensus that this is a good idea,
> it is rather the opposite.
>
> Not to get into interpretations of comments, but while I agree that there
> were one or two actual negatives, they were predicated on a
> misunderstanding of the purpose of the RFC. As such I took them as neutral,
> rather than negative. The remainder were questions or comments, and not
> negative ones.
>
> 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.


[Trying again, Sorry Paul who has likely received this three+ times nows]

[Resent without URLs, grrr]

Let me be absolutely clear:

Any attempt to improve HTTP request/response handling in PHP that doesn't
take into account WebSockets or HTTP/2 Server Push is a non-starter for me.

PSR-7 was heavily influenced by Python's WSGI spec and they are also seeing
it's inability to handle these types of interactions. As such there is a
new recommendation being proposed called ASGI: Asynchronous Server Gateway
Interface [1], that is intended to address this.

I think it would be more beneficial for PHP the language to consider
reaching out to the Python community and seeing if it makes sense to
collaborate on this. A new ASGI SAPI would come with message
objects/interfaces (see [1]) baked in.

If we want PHP to have a meaningful presence for the future web, we need to
move forward from our current request/response 1:1 HTTP-only model.

So, as currently proposed, I'm -1. It doesn't move the language forward in
any meaningful way.

- Davey

[1] google: ASGI python, it's the first result
2017-01-10 22:11 GMT+02:00 Davey Shafik <davey@php.net>:

> On Mon, Jan 9, 2017 at 10:43 AM, Paul Jones <pmjones88@gmail.com> wrote:
>
> >
> > > On Jan 7, 2017, at 15:41, Joe Watkins <pthreads@pthreads.org> wrote:
> > >
> > > That doesn't sound like a positive consensus that this is a good idea,
> > it is rather the opposite.
> >
> > Not to get into interpretations of comments, but while I agree that there
> > were one or two actual negatives, they were predicated on a
> > misunderstanding of the purpose of the RFC. As such I took them as
> neutral,
> > rather than negative. The remainder were questions or comments, and not
> > negative ones.
> >
> > 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.
>
>
> [Trying again, Sorry Paul who has likely received this three+ times nows]
>
> [Resent without URLs, grrr]
>
> Let me be absolutely clear:
>
> Any attempt to improve HTTP request/response handling in PHP that doesn't
> take into account WebSockets or HTTP/2 Server Push is a non-starter for me.
>
> PSR-7 was heavily influenced by Python's WSGI spec and they are also seeing
> it's inability to handle these types of interactions. As such there is a
> new recommendation being proposed called ASGI: Asynchronous Server Gateway
> Interface [1], that is intended to address this.
>
> I think it would be more beneficial for PHP the language to consider
> reaching out to the Python community and seeing if it makes sense to
> collaborate on this. A new ASGI SAPI would come with message
> objects/interfaces (see [1]) baked in.
>
> If we want PHP to have a meaningful presence for the future web, we need to
> move forward from our current request/response 1:1 HTTP-only model.
>
> So, as currently proposed, I'm -1. It doesn't move the language forward in
> any meaningful way.
>
> - Davey
>
> [1] google: ASGI python, it's the first result
>

I would also add the support, bug and feature issues that will definitely
crop up with such an interface. If there is a major bug, flaw or security
issue, getting it fixed is going to be a problem, because as we know, the
adoption of PHP is nowhere near instantaneous and it can be years before
you get the actual fix into the servers your project/projects are running
on, and you can't do anything about this.
There are also questions - a 1GB upload comes in, will interface implement
streams or some other way of handling that? Or there is a 200MB gallery
upload of images, with how most hosts set up their memory limits, I would
imagine this would just run out of memory. And all that stuff.

It's a way bigger job than I think the proposing person thinks, and it
needs major support from the project maintainers, because I'm 146% sure one
person will not be able to do it all and maintain it for next 10 years
before it becomes integral part of the core...

This is something that needs to be tested and runned as a module for quite
some time before it is stable enough to be in the core anyway - just see
what happened to PDO - as far as I know, no one really wants to touch it,
it's a mess.
Hi Arvids,

> On Jan 10, 2017, at 17:22, Arvids Godjuks <arvids.godjuks@gmail.com> wrote:
>
> I would also add the support, bug and feature issues that will definitely crop up with such an interface. If there is a major bug, flaw or security issue, getting it fixed is going to be a problem, because as we know, the adoption of PHP is nowhere near instantaneous and it can be years before you get the actual fix into the servers your project/projects are running on, and you can't do anything about this.

(/me nods) That particular problem is not specific to this RFC, though. It's true for anything that gets into PHP.


> There are also questions - a 1GB upload comes in, will interface implement streams or some other way of handling that? Or there is a 200MB gallery upload of images, with how most hosts set up their memory limits, I would imagine this would just run out of memory. And all that stuff.

Interesting -- what happens *now* without the ServerRequest RFC? If a 1GB upload comes in (or a 200MB gallery upload of images), then it gets dealt with under the RFC in exactly the same with PHP deals with it right now. That is: probably by attempting to store the uploads on disk, then exposing the file information via $_FILES.


> It's a way bigger job than I think the proposing person thinks, and it needs major support from the project maintainers, because I'm 146% sure one person will not be able to do it all and maintain it for next 10 years before it becomes integral part of the core...

It might well be a way bigger job than John & I think. However, I do have to point out that the vast majority of the functionality is pretty straightforward, and not terribly complex. It's certainly not at the PDO, XML, Filter, etc. level of intricacy.


> This is something that needs to be tested and runned as a module for quite some time before it is stable enough to be in the core anyway - just see what happened to PDO - as far as I know, no one really wants to touch it, it's a mess.

I can't speak to PDO, but I can say that APIs very similar to the one proposed in the RFC have been around for a long time, implemented by many different developers in many different systems. This RFC represents a summation and condensation of those behaviors.


--
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
On 12/01/2017 20:52, Paul Jones wrote:
>> I would also add the support, bug and feature issues that will definitely crop up with such an interface. If there is a major bug, flaw or security issue, getting it fixed is going to be a problem, because as we know, the adoption of PHP is nowhere near instantaneous and it can be years before you get the actual fix into the servers your project/projects are running on, and you can't do anything about this.
> (/me nods) That particular problem is not specific to this RFC, though. It's true for anything that gets into PHP.
>

Absolutely, which is why "getting into PHP" is a rare thing, and
"installable from PECL" is a perfectly respectable status to be in.

Regards,

--
Rowan Collins
[IMSoP]


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sorry, only registered users may post in this forum.

Click here to login