I'm running out of different ways to say the same thing, and not really
sure which part of my previous messages people haven't understood. I'm
really not saying anything very controversial or complicated, just "had
you considered that style B would offer these additional possibilities
over style A".
So I'm going to quote the parts of previous messages which I think
already answer the latest questions.
After that, I'm going to leave the thread to others for a bit, unless I
see a question that isn't just retreading the same ground.
On 01/01/2024 17:36, Pierre Joye wrote:
Unless I misunderstand the current proposal, it is about providing a
core interface to allow one to create its own SAPI similar to
FrankenPHP, which does not handle request in a singe thread but a
thread pool handled by go's coroutine.
From Kévin's opening post:
In addition to FrankenPHP, projects such as RoadRunner and Swoole provide
engines supporting worker modes.
[...]
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.
From my last message:
If we're attempting to standardise a new API for worker modes (i.e. HTTP servers which
are no longer "shared nothing"), choosing one which can be used by consecutive
worker modes (FrankenPHP , RoadRunner) but not concurrent ones (Swoole, ReactPHP, AMPHP)
feels like a big missed opportunity.
On 01/01/2024 17:40, Robert Landers wrote:
I'm not sure concurrent servers would even be able to be in scope if
we wanted them to be?
From my message dated 2023-12-29 22:55 UTC:
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.
On 01/01/2024 17:36, Pierre Joye wrote:
It is a first step and based on the usages/feedback, the next steps
could be the second part of your comment. Or?
From my message dated 2023-12-31 01:20 UTC:
if you standardise on an API that populates global state, you close off any
possibility of using that API in a concurrent environment. If you instead
standardise on callbacks which hold request and response information in their
own scope, you don't close anything off.
And from 2023-12-30 10:53 UTC:
The key requirement is that you have some way of passing the current request
and response around as scoped variables, not global state. That's essential for
any kind of concurrent run-time (async, thread-aware, etc).
Regards,
--
Rowan Tommins
[IMSoP]
