2017-01-10 22:11 GMT+02:00 Davey Shafik <da...@php.net>: > On Mon, Jan 9, 2017 at 10:43 AM, Paul Jones <pmjone...@gmail.com> wrote: > > > > > > On Jan 7, 2017, at 15:41, Joe Watkins <pthre...@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.
