No, because there is no change for 's' format which is all that PHP
5.2 produces. The 'S' format is produced only by PHP 6.
-Andrei
On Dec 14, 2006, at 7:40 PM, Mike Ho wrote:
Andrei, thanks for the patch.
When you initially posted a patch for serialization on this list, I
believe Ilia d
Andrei, thanks for the patch.
When you initially posted a patch for serialization on this list, I
believe Ilia did some quick, basic benchmarks and saw that the
patched version had a moderate negative performance impact.
Do you believe that this performance impact is still there?
--Mike
O
This is the patch against 5.2.1 that supports both 's' and 'S' in
serialized strings with no BC breaks. If there are no objections, I
will commit soon.
-Andrei
Index: ext/standard/var_unserializer.c
===
RCS file: /repository/php
I think 'v' with version info makes sense if we foresee multiple
serialization format changes in the future. The steps mentioned below
do not seem particularly practical for that reason. I would rather go
with a new type 'S' for escaped binary strings in both 6.0 and 5.2.1.
-Andrei
On Dec 7,
On Thu, December 7, 2006 9:17 am, Zeev Suraski wrote:
> At 13:35 07/12/2006, Stefan Esser wrote:
>>Guys,
>>
>>why can't you simply introduce a new variable type for serialized
>>strings like uppercase S:
>>There is absolutely no need for breaking backward compatibility.
>
> I can't think of a singl
Stefan Esser wrote:
Well, older version of PHP will be totally incapable of parsing it,
creating problems for the many people who use serialized strings as a
means of passing data between PHP applications. This would be an
especially big problem if you would want to add it to a pre-6.0 release.
Excuse me, I don't quite understand what you're concerned about. The
break would occur if you use PHP 6 serialized content in PHP 5, not
vice versa. I already said that having the same escape format in PHP
5.2 is not tractable for BC reasons and the support, as such, must be
left to PHP_Compat.
> Well, older version of PHP will be totally incapable of parsing it,
> creating problems for the many people who use serialized strings as a
> means of passing data between PHP applications. This would be an
> especially big problem if you would want to add it to a pre-6.0 release.
Uhmm you are m
On 7-Dec-06, at 10:17 AM, Zeev Suraski wrote:
At 13:35 07/12/2006, Stefan Esser wrote:
Guys,
why can't you simply introduce a new variable type for serialized
strings like uppercase S:
There is absolutely no need for breaking backward compatibility.
I can't think of a single reason not to u
At 13:35 07/12/2006, Stefan Esser wrote:
Guys,
why can't you simply introduce a new variable type for serialized
strings like uppercase S:
There is absolutely no need for breaking backward compatibility.
I can't think of a single reason not to use a new type like you suggest.
Can anybody thin
Guys,
why can't you simply introduce a new variable type for serialized
strings like uppercase S:
There is absolutely no need for breaking backward compatibility. If you
want to introduce
NEW features then introduce them and do not abuse old ones.
Stefan
Andrei Zmievski schrieb:
> I don't see a
On Thu, 2006-12-07 at 11:25 +0100, Thomas Seifert wrote:
> >From a users point of view: you must be kidding, eh?
> You want to break all the strings which were stored serialized in the
> 5.x-series? I can understand that it will break in php6 but not in some
> minor release.
> It will cause havoc w
>From a users point of view: you must be kidding, eh?
You want to break all the strings which were stored serialized in the
5.x-series? I can understand that it will break in php6 but not in some
minor release.
It will cause havoc with a lot of apps which can't read their cached- /
meta-data anymor
I don't see a way we can make it work for all the cases. I guess we'll
have to leave this task to PHP_Compat.
-Andrei
On Dec 1, 2006, at 3:03 PM, Ilia Alshanetsky wrote:
As it stands the current code breaks BC on decoding when the
serialized string contains \ characters.
For example:
Inp
As it stands the current code breaks BC on decoding when the
serialized string contains \ characters.
For example:
Input PHP 5.2 PHP 5.2
w/patch
We can put it in 5.3 perhaps.
-Andrei
On Dec 1, 2006, at 1:51 PM, Ilia Alshanetsky wrote:
Before we commit, let's explore how it will affect existing
applications. The last thing I want to do is break the serialization
format BC in a minor release.
On 1-Dec-06, at 4:43 PM, Andrei Zmievski
Hello Andrei,
this will be a problematic bc break as with the patch applied strings
suddenly behave pretty different. Until now our policy was to notintroduce
forward compatibility breaks.
best regards
marcus
Friday, December 1, 2006, 10:43:32 PM, you wrote:
> When serializing binary strings
Before we commit, let's explore how it will affect existing
applications. The last thing I want to do is break the serialization
format BC in a minor release.
On 1-Dec-06, at 4:43 PM, Andrei Zmievski wrote:
When serializing binary strings in PHP 6, we have to escape non-
ASCII characters a
When serializing binary strings in PHP 6, we have to escape non-ASCII
characters and then unescape them on unserialization. This patch adds
the unescapement support to PHP 5.2, in order to make it easier to
exchange data between PHP 5 and 6. If no one has objections, I will
commit soon.
-Andr
19 matches
Mail list logo
