Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » Per-request UG(unicode) »

Per-request UG(unicode)

php.internals

Andrei Zmievski

19 years ago
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

Andrei Zmievski

19 years ago
No comments? On Sep 27, 2006, at 10:03 AM, Andrei Zmievski wrote:

Richard Lynch

19 years ago
On Thu, September 28, 2006 11:44 am, Andrei Zmievski wrote:
> 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

Sara Golemon

19 years ago
>> 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

Stanislav Malyshev

19 years ago
> 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...

Derick Rethans

19 years ago
On Fri, 29 Sep 2006, Stanislav Malyshev wrote:
> > > 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

Andi Gutmans

19 years ago
What soup? Did you check out the patch? It's actually not bad at all. It's even cleaner than what we had previously as we just make sure we have two versions and we use the right one... Andi

Michael Wallner

19 years ago
Andrei Zmievski wrote:
> No comments?
I didn't have the time to look & try it yet.
-- Michael

Ilia A.

19 years ago
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

Andi Gutmans

19 years ago
What kind of hackery? Have you looked at the PHP 6 source code? This is like epsilon compared to the conditionals and "hacks" that had to be made for Unicode. In fact, this patch is insignificant compared to the other changes and provides VERY high value. Maybe in a purists view it's not great, but in real life, many many many users run more than one application on the same PHP server. Not supporting per-request Unicode in PHP 6 is going to be a huge mistake and will just screw our users, most of them not purists nor hackers.. Andi

Christian Schneider

19 years ago
Andi Gutmans wrote:
> Maybe in a purists view it's not great, but in real life, many many many > users run more than one application on the same PHP server. Not supporting > per-request Unicode in PHP 6 is going to be a huge mistake and will just > screw our users, most of them not purists nor hackers..
I agree with you there and I hope you can convince the others to accept the patch... Cheers, - Chris

Rasmus Lerdorf

19 years ago
Christian Schneider wrote:
> Andi Gutmans wrote: >> Maybe in a purists view it's not great, but in real life, many many many >> users run more than one application on the same PHP server. Not >> supporting >> per-request Unicode in PHP 6 is going to be a huge mistake and will just >> screw our users, most of them not purists nor hackers.. > > I agree with you there and I hope you can convince the others to accept > the patch...
It's not really about purism. It is about whether we can pull it off effectively. Safe-Mode, if actually safe, would help lots of users as well, but after many years of trying we have thrown in the towel on it. I worry whether attempting to get the best of both worlds here is another unreachable dream. Nobody is debating the merits of the idea, so restating yet again doesn't really do anything for the discussion. I worry about things that persist requests and how they will be affected by unicode semantics changing out from underneath it. For example, persistent database connections. They are created with a set of credentials which are compared on the subsequent requests to see if the existing connection can be re-used. With Unicode semantics flipping back and forth will this comparison now fail even though the credentials might actually match? How about cache opcode arrays. I don't see a flag in the op_array that says whether it was created in Unicode mode or not. Think about the case where the same include file is included in both Unicode and non-Unicode mode. How about the hundreds of extensions out there that do things in MINIT that persist across the life of the server. They would all have to be reviewed to make sure they aren't making assumptions at startup that aren't valid in the other mode. And worst-case and bunch of these would have to be moved from MINIT to RINIT to get around this. These are the sorts of things that the patch doesn't address that we should be talking about, not whether it would be a useful feature to users. We all agree it would be, but having a half-working feature wouldn't be. -Rasmus

Richard Lynch

19 years ago
On Tue, October 3, 2006 6:03 pm, Rasmus Lerdorf wrote:
> These are the sorts of things that the patch doesn't address that we > should be talking about, not whether it would be a useful feature to > users. We all agree it would be, but having a half-working feature > wouldn't be.
Would it be possible to better document on php.net the work-around of running a second pool of servers and proxy-forwarding or whatever the heck it is as a way to have both Unicode and non-Unicode running on one server, more or less seemlessly?... Not that I actually UNDERSTOOD that post Rasmus made to PHP-General describing how to do this, mind you, but it would at least provide a work-around for this issue -- maybe one that even large-scale webhosts could handle? Yes, I know, it's really an Apache setting, but still... It's what you need to do to get the job done. I'm just hoping to get the PHP 6 / Unicode adoption rate up to something better than glacial speeds...
-- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So?