> That sounds "good" in my ears. > > Software that relys on "old" non-unicode behaviour must be written in a > way two handle non-unicode and Unicode behaviour in two different ways. > But for example a rewritten "Squirrelmail" that runs exlusively on PHP6 > would be a good thing. > > So you could write on your release notes: "We have this new version > SquirrelMail++ that’s running only on hosts running PHP6. Using this would > be a great speed and performance increase, because the Unicode addons are > only available here. If you need an old non-unicode version, you have to > stay with our old historic version." The old historic Squirrelmail version > without Unicode support would be stays supported until some time. But all > users would know: If I want to have new features, I should think about a > change to PHP6, all other users could stay on the old version. > > In the case of the fantastic software "SquirrelMail++PHP6-only" (which I > would use on my servers, too) I would think in this direction!
There is nothing in current PHP6 version that can be used by SquirrelMail. Last features are provided by PHP 5.1.0. Limiting code to PHP6 would reduce user base. SquirrelMail can work on PHP6 with unicode.semantics=off, if two lines in one script are fixed. P.S. I am not SquirrelMail guy. I am former SquirrelMail developer and I use own modified SquirrelMail version. It does not have issues with Japanese. -- Tomas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
