Hi Robert, sob., 30 gru 2023, 10:59 użytkownik Robert Landers <landers.rob...@gmail.com> napisał:
> > > - 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. > That is certainly not true. Looking at WSGI or ASGI there is no need for request response objects. These can be provided in userland which gives more flexibility cause of different rules governing over bc break policy in PHP core. Name one true argument to convince me in this topic and I may change my mind. For the years I had the same impression but on low level the primitives are more flexible and we all know that. Cheers, Michał Marcin Brzuchalski >
