Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:54729
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.161.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CA+p1TcZVZOg+tyzPo-20xyxcxm0W+ET1aJ-+14V=Ff6AVmEFHw@mail.gmail.com>
References: <CAKxcST-n_aC1NJ8pLg5natwRRcxEHV_t-fiEhYX4mc=G7WPFaA@mail.gmail.com>
	<4E4E48F6.8010107@php.net>
	<CAEZPtU5uRFO+mhQTJDZm32_Y7k6p9HzZmn1YiRmW4iZQrmht9A@mail.gmail.com>
	<CAKxcST9AYTb+SJJydb0u5RK+XgP7og8KqH+1u-7trDrSJBPOKA@mail.gmail.com>
	<CAH-PCH56zYkJH8BaGHdKTUmBm6V+k_yxKfAVp9XuES_B5ps5CQ@mail.gmail.com>
	<CA+p1TcZ-_X7x7VdkhjeY86vC67PNmoZ93BcwuJ2uKdWJzhvFLQ@mail.gmail.com>
	<CAH-PCH7xRmE2Uc2smRtBiRyyxzvhBWux7E8naAV_0+y-9dv6Qg@mail.gmail.com>
	<CA+p1TcZVZOg+tyzPo-20xyxcxm0W+ET1aJ-+14V=Ff6AVmEFHw@mail.gmail.com>
Date: Fri, 19 Aug 2011 14:54:31 +0200
Message-ID: <CAH-PCH5qSOLPNvhxe7KwJutg6gQxmTnx04mDQhWB6p_xVoMq7g@mail.gmail.com>
To: Arpad Ray <arraypad@gmail.com>
Cc: Paul Dragoonis <dragoonis@gmail.com>, Pierre Joye <pierre.php@gmail.com>, 
	Sebastian Bergmann <sebastian@php.net>, internals@lists.php.net
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Activation of IGBinary serialization extension in 5.4
 by default
From: tyra3l@gmail.com (Ferenc Kovacs)

On Fri, Aug 19, 2011 at 2:47 PM, Arpad Ray <arraypad@gmail.com> wrote:
> On Fri, Aug 19, 2011 at 1:40 PM, Ferenc Kovacs <tyra3l@gmail.com> wrote:
>> On Fri, Aug 19, 2011 at 2:31 PM, Arpad Ray <arraypad@gmail.com> wrote:
>>> On Fri, Aug 19, 2011 at 1:04 PM, Ferenc Kovacs <tyra3l@gmail.com> wrote=
:
>>>> the downside would be that if you want to serialize/unserialize the
>>>> data outside of php, your implementation should take care of this
>>>> prefix.
>>>> just a wild idea, but maybe useful:
>>>> instead of creating a prefix, we could serialize the passed data with
>>>> the given(php, igbinary, etc.) handler, then wrap the whole stuff into
>>>> an array which holds the name of the used handler and the serialized
>>>> data, and serialize this array with the old(php) serialize method.
>>>> this way the datablob would be always a valid serialized string, and
>>>> would be easier to get the serialize method than with the prefixing.
>>>
>>> If my old app couldn't read some newly serialized string, I'd rather
>>> it failed hard than apparently succeed but have the wrong data.
>>>
>>
>> http://php.net/unserialize
>> In case the passed string is not unserializeable, FALSE is returned
>> and E_NOTICE is issued.
>> so if you unserialize from php, my suggestion would fail harder.
>> when you unserialize it from another mean (parsing it on your own, or
>> from a different language), you are right, it would produce a valid
>> but different result what you would expect, but this could be
>> documented, and I don't think that that many users do this, and maybe
>> they are using json/bson/igbinary already.
>
> I'm talking about unserialize() in an old (well, current) version of
> PHP - if it unserializes what is apparently a valid array there would
> be nothing to indicate it's actually a new version which it can't
> read.
>

I see, yeah, "old" clienst would still suffer from this, they would
get an array from unserialize what they didn't expect, and maybe some
data, what they cannot unpack (if it was packed with a method other
than the current)
the pro side is that it would be possible to handle this situation (if
you cannot upgrade a php instance for example for some reason) as you
could handle those situations (unserialize the data field to get the
original data, or use igbinary from pecl to decompress it, etc.)
I didn't feel too strong about this, just throwing ideas around.

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu