Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82195
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.41 as permitted sender)
Message-ID: <54D7F5D5.4050808@gmail.com>
Date: Sun, 08 Feb 2015 23:48:37 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CALW=WED82x9i0ea4MMuM3jkPknaBCmBPWExUyRKTDz-MPzif8g@mail.gmail.com>
In-Reply-To: <CALW=WED82x9i0ea4MMuM3jkPknaBCmBPWExUyRKTDz-MPzif8g@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] uWSGI experimental plugin for implementing a WSGI/PSGI/Rack-like
 interface for PHP
From: rowan.collins@gmail.com (Rowan Collins)

On 08/02/2015 22:48, S.A.N wrote:
> Hi internals.
>
> I really hope that in the future PHP 7, there will be new server API.
> May be you interested to know about them, here is the link, I am not
> the author of development:
> https://github.com/unbit/uwsgi-phpsgi/
>
> But the problem is that in PHP there are no standards for such interfaces.
> Now it is implemented like this:
>
> <?php
>
> function application($env)
> {
>   return ['200 OK', ['Content-Type' => 'text/plain'], 'Hello, world!'];
> }
>
> ?>
>
> I think this is a good opportunity to review the old interface ($_GET,
> $_POST, ...) and start using the API internal HTTP module.
>
> This all breaks backward compatibility, not $_GET, $_POST, ...
> But this WSGI SAPI will used only new PHP code (not PHP legacy base).
>
> This is a good opportunity to create something new and not be backward
> compatible.
>
> What do you think about this?

The problem with creating an event-based API for PHP is that you don't 
just have to rethink superglobals, you have to rethink absolutely 
everything that currently acts as global state:

- global variables
- static variables within functions
- class static variables
- dynamic settings (ini_set etc)
- globally registered callbacks (set_error_handler, 
spl_autoload_register, etc)
- the counters of include_once() and require_once()
- any function which implicitly fetches data based on some previous 
action (e.g. libxml_get_errors)

If the language is not itself multi-threaded, all of these become 
arbitrarily shared once per thread the server spins up and reuses. If it 
*is* multi-threaded, you have another set of headaches about how both 
the engine and the userland can share and synchronize.

Not that I don't like the idea, but it's a huge project, with potential 
for profoundly affecting the language.

Regards,

-- 
Rowan Collins
[IMSoP]