On 29/12/2023 21:14, Kévin Dunglas wrote:
On Fri, Dec 29, 2023 at 8:14 PM Rowan Tommins
<rowan.coll...@gmail.com> wrote:
- FrankenPHP expects the user to manage the main event loop ...
This isn't exact. FrankenPHP does manage the event loop (the Go
runtime manages it - through a channel - under the hood).
Perhaps "event loop" was the wrong term; what I was highlighting is that
to use FrankenPHP or RoadRunner, you have to write a while loop, which
explicitly handles one request at a time. In Swoole, there is no such
loop: you register event handlers and then call $server->run() once.
Similarly, WSGI mandates that the server "invokes the application
callable once for each request it receives from an HTTP client".
It's a distinction of pull/poll (the application must actively block
until next request) vs push/subscribe (the application is passively
invoked whenever needed).
I already replied to Crell about that. It will totally possible to
expose more complex HTTP message objects in the future,
but PHP currently lacks such objects. The only things we have are
superglobals (which are more or less similar to CGI variables, as done
in WSGI) and streams. It's why we're using them.
The use of objects vs arrays wasn't the main difference I was trying to
highlight there, but rather the overall API of how information gets into
and out of the application. FrankenPHP is the only server listed which
needs to reset global state on each request, because the others
(including Python WSGI and ASGI) use non-global variables for both input
and output.
I notice that the Laravel Octane adaptor for FrankenPHP takes that
global state and immediately converts it into non-global variables for
consumption by the application.
I'm not sure what you mean by "async PHP environment".
OpenSwoole, AMPHP, ReactPHP, etc - servers which expose concurrency
directly to the user of PHP. In those environments, global state isn't
just reused between consecutive requests, it's shared between multiple
requests running concurrently, so a global "current request" and
"current response" have no meaning.
WebSockets and WebTransport are a different kind of beast, they are
much lower level than HTTP and will require a different API anyway
(and probably a lot of other adaptations in core) to be supported in PHP.
WebSocket support in PHP is just as real as worker modes and
asynchronous concurrency.
Swoole has a WebSocket implementation included in core
[https://openswoole.com/docs/modules/swoole-websocket-server] and
Roadrunner has a plugin for it
[https://roadrunner.dev/docs/plugins-centrifuge/current] In both cases
(and in ASGI), the same basic API is used as with HTTP, but using a more
general concept of "events" in place of "requests".
Other PHP implementations include Ratchet [http://socketo.me/] and AMPHP
Websocket Server [https://github.com/amphp/websocket-server].
Note that both async and WebSockets were mentioned as possible "forward
compatibility". If we're talking about "next generation SAPIs", these
are the kinds of features that people will be - and already are -
developing; so it seems foolish not to at least consider them when
designing new baseline APIs.
Regards,
--
Rowan Tommins
[IMSoP]
