Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82376
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.175 as permitted sender)
Message-ID: <54D9F8EA.4020902@gmail.com>
Date: Tue, 10 Feb 2015 12:26:18 +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 <internals@lists.php.net>
References: <CALW=WED82x9i0ea4MMuM3jkPknaBCmBPWExUyRKTDz-MPzif8g@mail.gmail.com>	<54D7F5D5.4050808@gmail.com>	<CALW=WEC1SqJRMCKXZfu8Ds5ob3LXN-5tzVW67pRVHmVpEg8fMA@mail.gmail.com>	<54D7FEBA.1070304@gmail.com>	<CALW=WEBJ+fSTA8x1ADjPbUNGy_sjrZhN7krDnoi8-Up=3wFx-g@mail.gmail.com>	<860EABC1-CAFF-4FD1-8C59-2F2E06C9D8B8@gmail.com> <CALW=WEDuXCP=PShvjGwswioH++-VNM6npjhyNcHAWCSxDA_Ang@mail.gmail.com> <54D8FB43.3060204@gmail.com>
In-Reply-To: <54D8FB43.3060204@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)

Rowan Collins wrote on 09/02/2015 18:24:
> S.A.N wrote on 09/02/2015 17:40:
>> 2015-02-09 12:41 GMT+02:00 Rowan Collins <rowan.collins@gmail.com>:
>>> Yes, I can see it working well for specialised uses - you can simply 
>>> not use those aspects of the language that don't make sense. But for 
>>> it to be a mainstream part of the language, it needs to play nicely 
>>> with other parts of the language, and that's where I see it being a 
>>> complex and painful change.
>>>
>> The fact that the lack of native application server for PHP is often
>> the reason for leaving the PHP developers to other languages and
>> technologies.
>>
>> Let's see what others have in 2015:
>>
>> Python - WSGI
>> Ruby - Rack
>> Perl - PSGI
>> JavaScript - JSGI
>> Hack - HHVM
>>
>> PHP - No native application server in core.
>>
>> What discusses the PHP community?
>> Remove or not to remove the PHP4 constructors and many other issues
>> that do not add competitive ability PHP...
>>
>> I personally do not blame you :), just expressing his opinion
>> developer who wants to use PHP and can use modern app server in core
>> PHP.
>>
>
> The sentence you're replying to there is talking about existing 
> implementations, on top of current PHP, with all the limitations that 
> implies.
>
> My view on the general idea of changing the language so that 
> eventually an event-based model could be the norm, is in an earlier 
> reply:
>
> > Not that I don't like the idea, but it's a huge project, with 
> potential for profoundly affecting the language.

I just realised the double negative in that sentence may not be easy to 
understand, so just to make sure it's clear: I do quite like the idea, 
in general, but think it would require a major rethink of large parts of 
code. We need only look at PHP 6/Unicode for the risks involved in a 
well-intentioned feature with far-reaching impact on the language.

I also think that an application server model without userland threads 
would be a mistake, because it would still be difficult to share 
anything meaningful between requests.

That said, if someone wants to start collecting a top-level list of what 
would need to be changed, and suggesting how it might work, I'd be happy 
to contribute some ideas.

Regards,
-- 
Rowan Collins
[IMSoP]