RE: [PHP-DEV] RFC: unicode.semantics: runtime or not?

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 >