Activation of IGBinary serialization extension in 5.4 by default

Some others systems use something similar to syntax checking (ldap password
hashes).

Baisically, prefix a code to the serialized string to indicate what method
was used to serialize.

Eg no prefix, or $O$ for the old style.

Or $I$ for the igbinary syntax.

This has the advantage of allowing additional formats to be added over time
without breaking BC.

Kiall

On Thu, Aug 18, 2011 at 12:38 PM, Roger Llopart Pla <lumbendil@gmail.com
wrote:

I agree with bundling it in the core aswell, but having it as default, as
stated, would be a huge BC break.

2011/8/18 Arpad Ray arraypad@gmail.com

Hi,

On Thu, Aug 18, 2011 at 12:12 PM, Paul Dragoonis dragoonis@gmail.com
wrote:

Hey guys,

After a brief discussion with Pierre I'm taking this discussion to
here.
We have the igbinary pecl extension available [1], however not many of
our
userbase are familiar that it even exists.
Here [2] is the performance boost we get from using igbinary with
serialize() and unserialize().

Here we get a great perf boost, and what's more excellent as we don't
have
to break BC to get there!

It would break BC for anyone with serialized strings stored in the
current format.

Maybe bundle it in core and provide an ini setting like
session.serialize_handler, but I don't think making it the default in
5.4 is an option.

Sorry guys, I didn't realise there was an actual BC break in the
serialized
structure.
I agree with bundling and providing a .ini setting to activate, but off by
default.

Regards,

Arpad

This seems like a no-brainer and a good investment in the speed
increase
of
PHP by default for the future users of the platform.

[1] http://pecl.php.net/package/igbinary
[2] http://www.php.net/~pierre/vcqa/apcigninary_perf.png

Comments please.

Regards,
Paul Dragoonis.

I agree with bundling and providing a .ini setting to activate, but off by
default.

An ini setting is evil for this. People use serialized data as transport
format having that depend on an ini setting is bad.

suggestions:

• The decode function could check the format ("old" format will always
  begin by one of aisfb or so followed by a colon, igbinary something
  else)
• serialize() might get an extra parameter to set the format
• lateron, if we want: if old format is being use a deprecation notice
  is shown when the older fomrat is being used)

johannes

Dear All,

Again with my 2cents into the basket: I was hoping Ilia Alshanetsky
would also support this idea since in his talks (i.e.
http://ilia.ws/archives/241-IPC-Hidden-Features-of-PHP-Slides.html) he
has been promoting the exact same use: switch the standard serializer
to igBinary...

Also the proposed include it -> read the data -> convert on write if in
previous format (possibly an ini setting?) would provide full BC and
would allow a painless upgrade... wouldnt it?

--
With kind regards,

Robin Speekenbrink
Kingsquare Information Services

hi Stas!

. not enabling it by default defeats the purpose of bundling it

Actually, I don't think it does. It's one thing to tell people "put this
option into php.ini" and quite another is "download it from PECL (?),
compile it (?!) and install it". The first is wi
thin the limits of any
literate person, the second is sysadmin territory.

All major distros have it already, so it is the same. Now, if it is
not enabled by default, then many admins won't install it, back to the
same problem. It is very unlikely that someone with root or admin
perms won't be able to install an extra extension from the distro
repository or using the DLL on windows.

. easier to support it while being only in pecl ('do you use the core
version or latest pecl?")

It is a concern, if this extension is not stable yet. Is it?

It is stable. But the concern is not about its stability but the ease
of support. Having it in core means than some users may use (for
example) 5.4.2 version while we are at 5.4.6 or pecl has 3 new
versions. Not a big deal, just easier.

That being said, I'm not opposed to include it, I only don't see it as
a must go :)

Cheers,

$x = null;
get_class($x) returns get_class($this) as of 5.3.
I don't recall seeing a discussion of this on the list and
I can't find anything about this change in the archives.
The documentation is currently self-contradictory...

Under "Return Values":

Returns the name of the class of which object is an instance. Returns
FALSE if object is not an object.

Under "Changelog":

Since 5.3.0 NULL became the default value for object, so passing NULL
to object now has the same result as not passing any value.

(BTW, I don't see that listed in
http://us.php.net/ChangeLog-5.php#5.3.0 )

I guess there hasn't been a lot of screaming about it, so maybe
it isn't a big deal, but it seems like a significant BC break to
me. Maybe it's just because I've been beating my head against a
wall for so long trying to figure out why my code was behaving so
strangely. ;) I can't believe it's impossible to differentiate
between receiving an argument and not receiving an argument.
Would anyone really intentionally pass a null to this function
to get the result of get_class($this)?

Now that I know about this BC break, I'm OK and can avoid
the issue, but for the sake of the next person to hit this,
I felt I should post on the topic. I almost posted a bug
directly, but the behavior is documented, so I thought this
would be the correct place.

• Todd

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!

 Are you sure it does not break BC? Does http://bit.ly/nIRxqz still work
 with IGBinary, for instance?

That obviously won't work as long as igbinary is used. It is covered
by the  "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 so
it makes no sense to add more functions like serialize_binary() or whatnot.

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.

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu