On 08/19/2011 10:54 PM, Ferenc Kovacs wrote: > 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. > 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
