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, repeatedly > passing the server a function to be called once; it doesn't pass > anything into or out of the userland handler, instead resetting global > state to mimic a non-worker environment > [https://frankenphp.dev/docs/worker/#custom-apps] > This isn't exact. FrankenPHP does manage the event loop (the Go runtime manages it - through a channel - under the hood). The frankenphp_handle_request() pauses the thread until the Go runtime gives back control to the C thread (when a request is dispatched to this worker). It's actually very similar to WSGI. As I explained in my previous messages, it's expected that other SAPIs handle the event loop too (using the primitives provided by the language they are written in). > - RoadRunner doesn't use a callback at all, instead providing methods to > await a request and provide a response; it directly uses PSR-7 and > PSR-17 objects [https://roadrunner.dev/docs/php-worker/current/en] > - OpenSwoole manages the main loop itself, and uses lifecycle events to > interface to userland code; the HTTP 'Request' event is passed custom > Request and Response objects > [https://openswoole.com/docs/modules/swoole-http-server-on-request] > 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. If PHP adds a higher-level API at some point, we'll be able to upgrade this part as every other part of the PHP code base. But it's an unrelated topic: having such higher-level representations of HTTP messages would be beneficial both in "normal" and in "worker" mode. > it would be adapted for an async PHP environment, or with WebSockets, > for instance. > I'm not sure what you mean by "async PHP environment". 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. In Go, for instance, the WebSocket and WebTransport APIs aren't the same as the HTTP API. Best regards,
