Andi asked me to forward this, since it didn't go through to the list
on the first try.
Hi,
The following is a patch Dmitry did to change UG(unicode) to be
configurable
per-request. The guidelines from Andrei was that it shouldn't make the
extension code much more complicated and with this patch it doesn't.
As it
is, most of the logic is already decided upon at runtime so this patch
shouldn't have significant performance impact.
Some reasons to do it:
A) Per-virtual host configuration of UG(unicode) is very important for
any
server running multiple sites on the same machine.
B) Running multiple apps on the same machine will most probably
require some
apps to run with Unicode on and some with it off.
C) We are discovering some BC quirks with the current Unicode
implementation
(md5() for example). It's not clear if/how we can resolve those quotes
in a
transparent way or not. Making the UG(unicode) flag flexible will
significantly help in migrations which might be lengthier than expected
(having two versions in separate vhosts running on the same box for
migration purposes).Anyway, although the diff is big the change to extension authors is
very
minimal and we did the hard work already. Please check it out and see
if it
works on your machine. I think unless there are very significant
reasons not
to include this, we really should. Not allowing per-vhost selection of
Unicode setting will cripple PHP 6 for anyone who isn't running on a
dedicated server, and for some companies like Zend, who run more than
one
app on the same machine, it could also cripple things on dedicated
servers.Thx.
Andi
The patch is available at:
http://www.php.net/~andrei/u-5.diff
-Andrei
No comments?
Andi asked me to forward this, since it didn't go through to the list
on the first try.Hi,
The following is a patch Dmitry did to change UG(unicode) to be
configurable
per-request. The guidelines from Andrei was that it shouldn't make the
extension code much more complicated and with this patch it doesn't.
As it
is, most of the logic is already decided upon at runtime so this patch
shouldn't have significant performance impact.
Some reasons to do it:
A) Per-virtual host configuration of UG(unicode) is very important
for any
server running multiple sites on the same machine.
B) Running multiple apps on the same machine will most probably
require some
apps to run with Unicode on and some with it off.
C) We are discovering some BC quirks with the current Unicode
implementation
(md5() for example). It's not clear if/how we can resolve those
quotes in a
transparent way or not. Making the UG(unicode) flag flexible will
significantly help in migrations which might be lengthier than
expected
(having two versions in separate vhosts running on the same box for
migration purposes).Anyway, although the diff is big the change to extension authors is
very
minimal and we did the hard work already. Please check it out and see
if it
works on your machine. I think unless there are very significant
reasons not
to include this, we really should. Not allowing per-vhost selection of
Unicode setting will cripple PHP 6 for anyone who isn't running on a
dedicated server, and for some companies like Zend, who run more than
one
app on the same machine, it could also cripple things on dedicated
servers.Thx.
Andi
The patch is available at:
http://www.php.net/~andrei/u-5.diff
-Andrei
No comments?
I'm definitely +1 on the per-host configure option, if it's stable
enough to satisfy QA team.
Making migration to unicode apps easier is definitely a big win for
adoption.
--
Like Music?
http://l-i-e.com/artists.htm
No comments?
I'm definitely +1 on the per-host configure option, if it's stable
enough to satisfy QA team.Making migration to unicode apps easier is definitely a big win for
adoption.
Nooone is arguing that from the userspace side, having per-dir support for
setting the unicode flag is a good thing. It is. The question is: Is it
good enough to justify the soup that will become of the internal registries?
atm, I don't think it is...
-1
-Sara
Nooone is arguing that from the userspace side, having per-dir support for
setting the unicode flag is a good thing. It is. The question is: Is it
good enough to justify the soup that will become of the internal registries?
I'm not sure there really would be a soup. Yes, there would be two
copies of persistent system hashes - namely, class table and function
table - and probably there would be a need to deal with other persistent
tables like module lists in couple of places - but besides that there
should be not much of a soup...
Nooone is arguing that from the userspace side, having per-dir support for
setting the unicode flag is a good thing. It is. The question is: Is it
good enough to justify the soup that will become of the internal registries?I'm not sure there really would be a soup. Yes, there would be two copies of
persistent system hashes - namely, class table and function table - and
probably there would be a need to deal with other persistent tables like
module lists in couple of places - but besides that there should be not much
of a soup...
But that is already bad enough anyway. So would be -1 on this as well.
regards,
Derick
Andrei Zmievski wrote:
No comments?
I didn't have the time to look & try it yet.
--
Michael
After looking at the patch, I think that for the sake of code sanity
we need to keep this setting only inside php.ini only.
The amount of hackery per-request setting creates is just not worth
the convenience IMHO.
-1.
Ilia