# Per-request UG(unicode) - Thread: https://externals.io/message/25843 - Original archive: https://news-web.php.net/php.internals/25843 - Started by Andrei Zmievski on 2006-09-27T17:03:41+00:00 - Messages: 8 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #25843 — Andrei Zmievski — 2006-09-27T17:03:41+00:00 URL: https://externals.io/message/25843#25843 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 --- ## #25862 — Andrei Zmievski — 2006-09-28T16:44:09+00:00 URL: https://externals.io/message/25843#25862 · In reply to: #25843 No comments? > Andi asked me to forward this, since it didn't go through to the list > on the first try. > > > […] > > The patch is available at: > > http://www.php.net/~andrei/u-5.diff > > -Andrei --- ## #25865 — Richard Lynch — 2006-09-28T17:14:35+00:00 URL: https://externals.io/message/25843#25865 · In reply to: #25862 > 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 --- ## #25880 — Michael Wallner — 2006-09-29T06:35:51+00:00 URL: https://externals.io/message/25843#25880 · In reply to: #25862 Andrei Zmievski wrote: > No comments? I didn't have the time to look & try it yet. -- Michael --- ## #25897 — Sara Golemon — 2006-09-29T18:41:43+00:00 URL: https://externals.io/message/25843#25897 · In reply to: #25865 > > […] > > 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 --- ## #25899 — Stanislav Malyshev — 2006-09-29T21:10:36+00:00 URL: https://externals.io/message/25843#25899 · In reply to: #25897 > 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... --- ## #25912 — Ilia Alshanetsky — 2006-10-03T02:22:42+00:00 URL: https://externals.io/message/25843#25912 · In reply to: #25843 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 --- ## #25913 — Derick Rethans — 2006-10-03T08:45:46+00:00 URL: https://externals.io/message/25843#25913 · In reply to: #25899 > > > […] > > 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