Hi all,
I'd like to set the world on fire before disappearing off for the rest of
the day, so bear with me :)
PHP 5.3 appears (to me at least) ready for release, give or take a bit of
ironing. The only problem is the one of other-version compatibility, which
really is a PHP 6 issue. We can't (well we can but it doesn't work well)
future-proof our code with any certainty that we're doing so correctly. That
goes for both internal code (where it matters slightly less in that it
doesn't affect users) and userland code (where it matters a lot).
If you adapt userland code in PHP 5.3 to run under PHP 6, you lose back
compatibility prior to PHP 5.2.1.
If this changes in PHP 6 after PHP 5.3 is released, ie PHP 6 is made more
BC-friendly at too late a stage, there are likely to be an awful lot of
users complaining about their wasted time re-writing code when they had to
make a choice between FC and BC.
I therefore see tackling the BC issues in PHP 6 as a priority at this point
for this reason. I know a handful of developers (Tony, Scott, Andrei to name
the main movers at present) are ready to start working on HEAD again once
its direction is settled, and I'm concerned it's all going to come too late
to prevent a minor crisis of confidence.
So can we focus on 6 for a bit please? Like, make it Unicode-only and iron
out the BC issues arising from that as far as is possible?
Thanks,
- Steph
2008/5/30 Steph Fox steph@zend.com:
Hi all,
I'd like to set the world on fire before disappearing off for the rest of
the day, so bear with me :)
At this stage, I was going to say "Congratulations, go off and enjoy
yourself. You deserve it!".
Then I read the rest of the message. Now I realize it wasn't an
announcement of a new l'amour.
PHP 5.3 appears (to me at least) ready for release, give or take a bit of
ironing.
Win32 mail() doesn't.
The only problem is the one of other-version compatibility, which
really is a PHP 6 issue. We can't (well we can but it doesn't work well)
future-proof our code with any certainty that we're doing so correctly. That
goes for both internal code (where it matters slightly less in that it
doesn't affect users) and userland code (where it matters a lot).If you adapt userland code in PHP 5.3 to run under PHP 6, you lose back
compatibility prior to PHP 5.2.1.If this changes in PHP 6 after PHP 5.3 is released, ie PHP 6 is made more
BC-friendly at too late a stage, there are likely to be an awful lot of
users complaining about their wasted time re-writing code when they had to
make a choice between FC and BC.I therefore see tackling the BC issues in PHP 6 as a priority at this point
for this reason. I know a handful of developers (Tony, Scott, Andrei to name
the main movers at present) are ready to start working on HEAD again once
its direction is settled, and I'm concerned it's all going to come too late
to prevent a minor crisis of confidence.So can we focus on 6 for a bit please? Like, make it Unicode-only and iron
out the BC issues arising from that as far as is possible?Thanks,
- Steph
--
--
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
PHP 5.3 appears (to me at least) ready for release, give or take a bit of
ironing.Win32
mail()doesn't.
That's 'a bit of ironing'. The point of the post was:
So can we focus on 6 for a bit please? Like, make it Unicode-only and
iron
out the BC issues arising from that as far as is possible?
Thanks,
- Steph
Hi!
PHP 5.3 appears (to me at least) ready for release, give or take a bit of
ironing.
I was under impression parser multibyte support wasn't yet fixed. Was it?
--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hi!
PHP 5.3 appears (to me at least) ready for release, give or take a
bit of
ironing.I was under impression parser multibyte support wasn't yet fixed.
Was it?
Maybe we should decide if this a show stopper or not. From my
understanding we still do not have any example of this being used in
the wild ..
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
PHP 5.3 appears (to me at least) ready for release, give or take a
Will PHP 5.3 be released with fileinfo or will be still me made to use
hacks to detirmine mime types?
Kevin
Kevin Waterson wrote:
PHP 5.3 appears (to me at least) ready for release, give or take a
Will PHP 5.3 be released with fileinfo or will be still me made to use
hacks to detirmine mime types?
Just stumbled on this one myself ....
The Linux guys have put in a 'nice improvement to attachment handling' and
when I dropped it onto the windows machine nothing worked :(
( Note - re discussions in other threads - I've just spent most of my weekend
making what was a perfectly functional application work again in windows, but
I still have to find out why finfo_open simply does not find the working
directory that I have magic.mime - or is that just magic - is stored in )
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
Hi!
Maybe we should decide if this a show stopper or not. From my
We had this functionality in 5.x. People used it. There's no reason to
drop it except for patch authors not implementing it.
I think it's just wrong to submit patch dropping significant chunk of
PHP engine functionality, and then deciding - bah, I don't feel like
fixing it, so let's just ignore it as if it never existed. Remember,
most of PHP users - and even more so for non-US users - don't read
internals@ and know nothing about it. You can't just post a note in a
disused lavatory^W^Winternal developers list and expect all millions of
users to be informed. We don't really want to be the Vogons for PHP
users, do we?
understanding we still do not have any example of this being used in the
wild ..
It is used by Japanese users, please look at the archives.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hi!
Maybe we should decide if this a show stopper or not. From my
We had this functionality in 5.x. People used it. There's no reason
to drop it except for patch authors not implementing it.I think it's just wrong to submit patch dropping significant chunk
of PHP engine functionality, and then deciding - bah, I don't feel
like fixing it, so let's just ignore it as if it never existed.
Remember, most of PHP users - and even more so for non-US users -
don't read internals@ and know nothing about it. You can't just post
a note in a disused lavatory^W^Winternal developers list and expect
all millions of users to be informed. We don't really want to be the
Vogons for PHP users, do we?understanding we still do not have any example of this being used
in the
wild ..It is used by Japanese users, please look at the archives.
right .. so it was mentioned .. show us the code.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
-----Original Message-----
From: Lukas Kahwe Smith [mailto:mls@pooteeweet.org]
Sent: Saturday, June 14, 2008 3:10 PM
To: Stas Malyshev
Cc: Steph Fox; internals
Subject: Re: [PHP-DEV] New flameI was under impression parser multibyte support wasn't yet fixed.
Was it?Maybe we should decide if this a show stopper or not. From my
understanding we still do not have any example of this being used in
the wild ..
This is used when reading scripts that are in encodings like Shift-JIS
which is very common in Japan.
In any case, I have tried to get involvement from some people I know
over there without much success.
My preference would be to push out a beta ASAP to start solicitation
feedback and start the process (which will take quite a bit of time
anyway and is likely to require at least a couple of betas and probably
2-4 RCs). At some point one just has to draw the line and get things
going or we'll have infinite feature creep. Even though many may be
legit there are other versions of PHPs coming out and also the RM can
make some exceptions during the beta cycle if the changes are low risk
and make sense (this has been common practice so far).
This is also likely to wake up our friends in the far east who have a
vested interest in keeping multibyte enabled in the scanner and we can
then work with them to use the PHP 5.2.x code where possible if/when
they wake up and scream...
Andi
From: Lukas Kahwe Smith [mailto:mls@pooteeweet.org]
I was under impression parser multibyte support wasn't yet fixed.
Was it?Maybe we should decide if this a show stopper or not. From my
understanding we still do not have any example of this being used in
the wild ..This is used when reading scripts that are in encodings like Shift-JIS
which is very common in Japan. In any case, I have tried to get
involvement from some people I know over there without much success.
I've asked around a bit as well with our customers/partners, and all
they seem to answer is "we simply use UTF-8".
regards,
Derick
--
Derick Rethans
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org
From: Lukas Kahwe Smith [mailto:mls@pooteeweet.org]
I was under impression parser multibyte support wasn't yet fixed.
Was it?Maybe we should decide if this a show stopper or not. From my
understanding we still do not have any example of this being used in
the wild ..This is used when reading scripts that are in encodings like Shift-
JIS
which is very common in Japan. In any case, I have tried to get
involvement from some people I know over there without much success.I've asked around a bit as well with our customers/partners, and all
they seem to answer is "we simply use UTF-8".
At this point there is no 1st hand user known. There is no example
code. At the same time a lot of core developers question if the code
is even able to work in any reliable and secure way. Finally the
feature is not even documented.
As such the conclusion can only be that investing any time in readding
this "feature" would be a bad idea. If anyone actually uses this
feature they will have to come out of the woodwork now or when 5.3 is
out. At this point we might have enough information to actually
understand how that feature is used and how we can add it to 5.3.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello Lukas,
As such the conclusion can only be that investing any time in readding
this "feature" would be a bad idea. If anyone actually uses this feature
they will have to come out of the woodwork now or when 5.3 is out. At
this point we might have enough information to actually understand how
that feature is used and how we can add it to 5.3.
I really don't know what is so hard for you understand with this
feature. It switches the Zend Parser into another encoding that is used
when reading from blah.php files. (okay there is also some auto
detecting magic).
The reason for this is very simple. It allows you to write f.e. Japanese
in strings. If you use Shift-JIS then several Japanese characters will
not work in single byte PHP. The backslash (escaping) character is part
of several Japanese characters. In single byte PHP these characters are
wrongly considered as escape sequences by the parser while the
multi-byte parser realises that they are not escape sequences.
The same is true for chinese people using GBK. (afaik GBK is not
completely within utf-8)
Stefan Esser
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkhhBgwACgkQSuF5XhWr2nivWwCghOHAq9l0wrORJ9/3d7a4/RTz
Qp0AoJj3zqjxjTgEs1JlJZK5TftsCHcG
=rTY0
-----END PGP SIGNATURE
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
This is used when reading scripts that are in encodings like Shift-JIS
which is very common in Japan. In any case, I have tried to get
involvement from some people I know over there without much success.I've asked around a bit as well with our customers/partners, and all
they seem to answer is "we simply use UTF-8".
It is very unlikely that anyone on internals uses Shift-JIS (EUC-xx).
Mainly because (nearly) noone here is Japanese (Korean, Chinese).
However google for phpinfo() and you will see that zend_multibyte is
compiled into several PHP servers. You can also google for Shift-JIS and
co...
The problem here is that newer Asian systems will use UTF-8 (except
those nations using characters not possible in utf-8) and therefore the
customers of the PHP developers (on this list) will not need that
support. However there are many legacy systems out there who depend on
this feature. They most probably don't know about this discussion or
internals at all, so they cannot speak up.
If PHP 5.3 drops this feature it might close some multibyte security
problems. However this also means that all those
Japanese/Chinese/Korean/Taiwanese/... multibyte scripts will not run
anymore. This forces systems to stay on PHP 5.2 which will most probably
don't get security updates once PHP 5.3 is out of the door.
Stefan Esser
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkhhAu0ACgkQSuF5XhWr2njCswCcDCyWnFi4jInpX+BPhmSp6ec7
pAEAoKfDzhhpFKifgwlsn99WMwkve5bp
=2qIJ
-----END PGP SIGNATURE
If PHP 5.3 drops this feature it might close some multibyte security
problems. However this also means that all those
Japanese/Chinese/Korean/Taiwanese/... multibyte scripts will not run
anymore. This forces systems to stay on PHP 5.2 which will most
probably
don't get security updates once PHP 5.3 is out of the door.
And if they then still do not file bug reports, then there is nothing
we can do to help. Or maybe someone needs to write a script that looks
for those servers on google and tries to send to webmaster@[domain] ..
are there no PHP UGs, PHP conferences, mailing lists or whatever in
Japan? Isnt there a big translation team active on the Japanese
documentation? Anyways, I do not know these guys and this topic has
been lingering in "myth" stage for months now.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
W liście Stefan Esser z dnia wtorek 24 czerwca 2008:
The problem here is that newer Asian systems will use UTF-8 (except
those nations using characters not possible in utf-8) and therefore the
customers of the PHP developers (on this list) will not need that
support.
UTF-8 can express all characters in the Unicode. Do you mean that unicode
still lacks some characters for asian languages used today?
--
Paweł Stradomski
Paweł Stradomski wrote:
W liście Stefan Esser z dnia wtorek 24 czerwca 2008:
The problem here is that newer Asian systems will use UTF-8 (except
those nations using characters not possible in utf-8) and therefore the
customers of the PHP developers (on this list) will not need that
support.UTF-8 can express all characters in the Unicode. Do you mean that unicode
still lacks some characters for asian languages used today?
Some some minor inconsistencies, between Shift-JIS and Unicode.
http://en.wikipedia.org/wiki/Unicode#Mapping_to_legacy_character_sets
Asbjørn Sloth Tønnesen wrote:
Some some minor inconsistencies, between Shift-JIS and Unicode.
http://en.wikipedia.org/wiki/Unicode#Mapping_to_legacy_character_sets
And I say good riddance! The yen/backslash conflation has given me
plenty a PITA in the past.
--
Edward Z. Yang GnuPG: 0x869C48DA
HTML Purifier http://htmlpurifier.org Anti-XSS Filter
[[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]]