RFC: unicode.semantics: runtime or not? View as Markdown

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).

I agree that #1 is more robust, and altogether simpler.

However, I think that this will heavily affect the PHP 6 adoption
rate... especially for virtual hosters. If, for example,
register_globals had no PERDIR/per-vhost capability, I'd still have
applications that I couldn't run (... mostly from cvs.php.net).

Therefore, from an end-user/sysadmin standpoint, I'd have to go with #2.

S

Andrei Zmievski wrote:

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).

I think it would be best for all of us to go the more robust route
and make unicode.semantics only changeable in php.ini.

Regards,

Michael

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

From a technical perspective it makes sense to keep it php.ini only
setting or as Sara insists (STARTUP phase only). However, from a user
(hosting companies) perspective it adds a fair degree of complexity
to their setup, which would probably mean one php6 instance will need
to run as CGI or FCGI, which will without a doubt affect adoption
rates and/or or unicode.semantics being enabled by default on most
installs.

Personally, I think we'd be better off with a slower adoption rate,
but a more robust PHP without added engine/language complexity per-
dir unicode.semantics would add.

Ilia Alshanetsky

Hello,

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.

I believe that too. It is not only more robust but will also ease your/our life.

--Pierre

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

--
To
unsubscribe, visit: http://www.php.net/unsub.php

Hello Andrei,

we have already a freaking complexapi to deal with and on the other hand
we have fastcgisupport. What we should imo do is trying to drop complexity
of our api and not increase it to an unhandable extreme and instead promote
usage of fastcgi. My 2c.

best regards
marcus

Wednesday, September 6, 2006, 6:39:57 PM, you 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.

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).