(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
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
(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 usepecl_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, whereasheader(),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.comModernizing Legacy Applications in PHP
https://leanpub.com/mlaphpSolving the N+1 Problem in PHP
https://leanpub.com/sn1php
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.
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. :-)
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
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
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.
Bundling the [PSR-7] interface is no biggie, so I suggest steering away
and going that wayIt'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 ifnot 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 contextI 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 againI'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. :-)
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.comModernizing Legacy Applications in PHP
https://leanpub.com/mlaphpSolving the N+1 Problem in PHP
https://leanpub.com/sn1php
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
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]
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:
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,
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
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]