Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:54764
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.210.172 as permitted sender)
Message-ID: <4E51998B.9060301@gmail.com>
Date: Mon, 22 Aug 2011 09:49:31 +1000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: internals@lists.php.net
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> <CAH-PCH5qSOLPNvhxe7KwJutg6gQxmTnx04mDQhWB6p_xVoMq7g@mail.gmail.com>
In-Reply-To: <CAH-PCH5qSOLPNvhxe7KwJutg6gQxmTnx04mDQhWB6p_xVoMq7g@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Activation of IGBinary serialization extension in 5.4
 by default
From: davidkmuir@gmail.com (David Muir)

On 08/19/2011 10:54 PM, Ferenc Kovacs wrote:
> 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.
>
Why not provide a userland fallback?

eg: /IGBinary/unserialize()

It could unserialize the string, albeit slowly, but still give you
access to the data without needing the extension. At least that way you
have something rather than nothing.

David