On Fri, Aug 19, 2011 at 1:40 PM, Ferenc Kovacs <[email protected]> wrote:
> On Fri, Aug 19, 2011 at 2:31 PM, Arpad Ray <[email protected]> wrote:
>> On Fri, Aug 19, 2011 at 1:04 PM, Ferenc Kovacs <[email protected]> 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.
Regards,
Arpad