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]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
