Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122063
Content-Type: multipart/alternative;
 boundary="------------om8vrF75Ti1acK0TxzoU8dG7"
Message-ID: <6f7815b9-80cc-4e08-819a-49dca090116f@gmail.com>
Date: Fri, 29 Dec 2023 22:55:55 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-GB
To: internals@lists.php.net, =?UTF-8?Q?K=C3=A9vin_Dunglas?= <kevin@dunglas.fr>
References: <CADU7aovcatZ++PSg0Pt0-kXJH9Oe09N0jy5uXEoBYoRv6GeUwQ@mail.gmail.com>
 <5060b986-2e5a-46e4-9c83-763e5b155e83@gmail.com>
 <CADU7aoutXwr2puZnzMJk+iNfxf-xE-2DKviSTHLK+TR3xpzsQA@mail.gmail.com>
In-Reply-To: <CADU7aoutXwr2puZnzMJk+iNfxf-xE-2DKviSTHLK+TR3xpzsQA@mail.gmail.com>
Subject: Re: [PHP-DEV] RFC proposal: worker mode primitives for SAPIs
From: rowan.collins@gmail.com (Rowan Tommins)

--------------om8vrF75Ti1acK0TxzoU8dG7
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 29/12/2023 21:14, Kévin Dunglas wrote:
> On Fri, Dec 29, 2023 at 8:14 PM Rowan Tommins 
> <rowan.collins@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]

--------------om8vrF75Ti1acK0TxzoU8dG7--