Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:25553
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)
To: "'Andrei Zmievski'" <andrei@gravitonic.com>,
	"'PHP Internals'" <internals@lists.php.net>
Cc: "'Dmitry Stogov'" <dmitry@zend.com>
Date: Wed, 6 Sep 2006 12:40:53 -0700
Message-ID: <020201c6d1ec$5f1a3d40$fb02fea9@zend.2k>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcbR0tQxfdX5Z6ptR8aKd6uF6YgeKwAGNoiQ
In-Reply-To: <2b9a524b62303d2b7c3f5e20a7b86537@gravitonic.com>
Subject: RE: [PHP-DEV] RFC: unicode.semantics: runtime or not?
From: andi@zend.com ("Andi Gutmans")
References: <2b9a524b62303d2b7c3f5e20a7b86537@gravitonic.com>

As Andrei knows, I believe that not allowing to tune this on a per virtual
host basis, is going to make life very hard for our users. A huge part of
our users are hosting providers, or companies running multiple applications
on the same machine. Probably a majority do not own dedicated boxes. This
kind of limitation is going to not only slow down PHP 6 adoption, but I
think it may also significantly impair PHP as a hosting friendly solution,
and therefore, we could actually see a loss in overall PHP market share.

I suggest to first make the theoreticaly decision that we prefer to support
this on a per-request if it's feasible. When I say feasible it means with
some but minimal pain. If it becomes a disaster we should re-evaluate. I'll
try and spend the next week to try and see what the issues are and whether
we can resolve them in an acceptable way.

Andi
 

> -----Original Message-----
> From: Andrei Zmievski [mailto:andrei@gravitonic.com] 
> Sent: Wednesday, September 06, 2006 9:40 AM
> To: PHP Internals
> Cc: Dmitry Stogov
> Subject: [PHP-DEV] RFC: unicode.semantics: runtime or not?
> 
> 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.
> 
> 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).
> 
> -Andrei
> 
> --
> PHP Internals - PHP Runtime Development Mailing List To 
> unsubscribe, visit: http://www.php.net/unsub.php
>