Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:54723
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAKxcST9AYTb+SJJydb0u5RK+XgP7og8KqH+1u-7trDrSJBPOKA@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>
Date: Fri, 19 Aug 2011 14:04:31 +0200
Message-ID: <CAH-PCH56zYkJH8BaGHdKTUmBm6V+k_yxKfAVp9XuES_B5ps5CQ@mail.gmail.com>
To: Paul Dragoonis <dragoonis@gmail.com>
Cc: 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 1:42 PM, Paul Dragoonis <dragoonis@gmail.com> wrote=
:
> On Fri, Aug 19, 2011 at 12:36 PM, Pierre Joye <pierre.php@gmail.com> wrot=
e:
>
>> On Fri, Aug 19, 2011 at 1:28 PM, Sebastian Bergmann <sebastian@php.net>
>> wrote:
>> > Am 18.08.2011 13:12, schrieb Paul Dragoonis:
>> >> Here we get a great perf boost, and what's more excellent as we don't
>> have
>> >> to break BC to get there!
>> >
>> > =C2=A0Are you sure it does not break BC? Does http://bit.ly/nIRxqz sti=
ll work
>> > =C2=A0with IGBinary, for instance?
>>
>> That obviously won't work as long as igbinary is used. It is covered
>> by the =C2=A0"interop" or BC break parts in my initial reply.
>>
>
> So far, it looks like this "transparent" upgrade isn't that transparent
> anymore and will result in BC breaks. New approaches must be thought of.
>
> Like Pierre said, there will be new serialization engines in the future s=
o
> it makes no sense to add more functions like serialize_binary() or whatno=
t.
>
> I think we need to keep our code base identical and maintain the
> serialize_handler via our php.ini configuration.

this could still cause problems, as pointed out before (when you
change your handler, or when you pass serialized data between
different php installs, etc.), so I really like what Kiall Mac Innes
suggested: prefix the data with the serializer identifier.
if it is missing,  then it was serialized with the old method, if it
is present, the appropriate method should be used, if the serializer
ident is there but unknown, then exit with a fatal error telling the
user that the custom handler is missing.

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.

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu