Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:25540
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 80.74.107.235 as permitted sender)
Message-ID: <44FEFC0B.1000404@zend.com>
Date: Wed, 06 Sep 2006 20:49:15 +0400
User-Agent: Thunderbird 1.5.0.5 (X11/20060719)
MIME-Version: 1.0
To: Andrei Zmievski <andrei@gravitonic.com>
CC: PHP Internals <internals@lists.php.net>, 
 Dmitry Stogov <dmitry@zend.com>
References: <2b9a524b62303d2b7c3f5e20a7b86537@gravitonic.com>
In-Reply-To: <2b9a524b62303d2b7c3f5e20a7b86537@gravitonic.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] RFC: unicode.semantics: runtime or not?
From: antony@zend.com (Antony Dovgal)



On 06.09.2006 20:39, Andrei Zmievski wrote:
> We really need to settle on whether we want unicode.semantics to be 
> changeable at runtime or not. During early development it was 
> ZEND_INI_PERDIR, meaning that it could be changed in .htaccess and 
> VirtualHost blocks. However, the infrastructure to support this 
> flexibility was deemed too complicated at the Paris PDM. Basically, we 
> need to maintain two sets of symbol tables and convert between them on 
> the fly as well as two copies of each class entry. The latter was 
> especially problematic instead of just mentioning class entry pointer, 
> you had to access it like U_CLASS_ENTRY(ce). So it was decided that 
> unicode.semantics switch would be only ZEND_INI_SYSTEM and that is how 
> the development proceeded since then. However, there have come up 
> concerns that keeping it this way will make PHP 6 adoption infeasible 
> by the majority of hosting companies and users since they would have to 
> run two copies of Apache to support both modes.

I think making it INI_PERDIR would mean a lot of headache and overcomplicated code in the engine and the extensions that modify its behaviour (like APC).

AFAIK lot of shared hosters provide PHP4 as Apache module and PHP5 as CGI atm.
This is also possible with PHP5 and PHP6, in which case the INI_SYSTEM limitations do not really matter, since it's only per request.

> We can go back to the PERDIR version, but that requires a lot of work 
> and not just in the engine, but also in a lot of extensions. I will let 
> Dmitry provide the technical details, but we need to decide which way 
> to go:
> 
> 1. ZEND_INI_SYSTEM and make people run two copies of Apache if they 
> want both modes. This is architecturally more simple and more robust, I 
> believe.

> 2. ZEND_INI_PERDIR and let people switch modes as described above. This 
> is a lot of work and will probably result in quite a few edge cases 
> where we used to rely on stability of one mode (such as APC or 
> serialization, for example).


-- 
Wbr, 
Antony Dovgal