> > - 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 think these models have different capabilities: A pull/poll model is quite simple, while a subscription model is usually more complex. With something simple like in FrankenPHP, creating a Queue SAPI, a WebSocket SAPI, etc isn't far off, where someone writes some PHP to consume a queue or websocket connections. > > 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. For this to happen in PHP Core, there would need to be request objects instead of a global state. If an RFC implementing PSR requests/responses in Core is a pre-requisite for enabling what we're discussing here, I'd personally be all for that (as would a very large chunk of the PHP community, IMHO). I personally think this is a chicken/egg type of problem though. It doesn't make sense to have request/response objects right now, and I get the feeling that people would only support worker mode primitives if there were request objects... so, it might make sense to build a v1 of the worker mode primitives and then iterate towards request objects, because then there would be an actual need for them. Robert Landers Software Engineer Utrecht NL -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
