On Fri, Aug 19, 2011 at 2:47 PM, Arpad Ray <array...@gmail.com> wrote: > On Fri, Aug 19, 2011 at 1:40 PM, Ferenc Kovacs <tyr...@gmail.com> wrote: >> On Fri, Aug 19, 2011 at 2:31 PM, Arpad Ray <array...@gmail.com> wrote: >>> On Fri, Aug 19, 2011 at 1:04 PM, Ferenc Kovacs <tyr...@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. -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
