Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122061
Content-Type: multipart/alternative;
 boundary="------------V0YC0qFBECltzOeUtFrJuEwA"
Message-ID: <5060b986-2e5a-46e4-9c83-763e5b155e83@gmail.com>
Date: Fri, 29 Dec 2023 19:14:30 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: internals@lists.php.net
References: <CADU7aovcatZ++PSg0Pt0-kXJH9Oe09N0jy5uXEoBYoRv6GeUwQ@mail.gmail.com>
Content-Language: en-GB
In-Reply-To: <CADU7aovcatZ++PSg0Pt0-kXJH9Oe09N0jy5uXEoBYoRv6GeUwQ@mail.gmail.com>
Subject: Re: [PHP-DEV] RFC proposal: worker mode primitives for SAPIs
From: rowan.collins@gmail.com (Rowan Tommins)

--------------V0YC0qFBECltzOeUtFrJuEwA
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 23/12/2023 20:34, Kévin Dunglas wrote:
> In addition to sharing code, maintenance, performance optimization, etc.,
> the existence of a common infrastructure would standardize the way worker
> scripts are created and provide a high-level PHP API for writing worker
> scripts that work with all SAPIs that rely on this new feature.


While this seems like a noble aim, there doesn't seem to be much 
consensus on what such an API should look like; from what I can see:

- 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]
- 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]

It also seems relevant to mention the situation in Python:

- WSGI specifies a Python-level interface between a web server and a web 
application / framework. The server side is expected to provide the 
event loop (unlike in FrankenPHP), and passes the application an 
environment dictionary (based on CGI) and a start_response callback. 
[https://peps.python.org/pep-3333/]
- The newer ASGI generalises this interface into an asynchronous event 
handling system, including support for WebSockets. 
[https://asgi.readthedocs.io/en/latest/introduction.html]

Out of all of these, the FrankenPHP approach seems to be the most basic, 
providing good backwards compatibility with PHP's normal "shared 
nothing" approach, but not much forwards compatibility - I can't see how 
it would be adapted for an async PHP environment, or with WebSockets, 
for instance. I'm sceptical how many SAPIs would actually implement it, 
rather than providing more powerful APIs.

Regards,

-- 
Rowan Tommins
[IMSoP]

--------------V0YC0qFBECltzOeUtFrJuEwA--