The gain is that those without the extension can still unserialize the
data and read it. It solves the problem discussed where older versions
of PHP without IGBinary built in would be locked out from being able to
unserialise data.
Didn't realise the reply was private. I did a reply-to-list, but
T
On Mon, Aug 22, 2011 at 1:49 AM, David Muir wrote:
> 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 n
On 08/19/2011 10:54 PM, Ferenc Kovacs wrote:
> On Fri, Aug 19, 2011 at 2:47 PM, Arpad Ray wrote:
>> On Fri, Aug 19, 2011 at 1:40 PM, Ferenc Kovacs wrote:
>>> On Fri, Aug 19, 2011 at 2:31 PM, Arpad Ray wrote:
On Fri, Aug 19, 2011 at 1:04 PM, Ferenc Kovacs wrote:
> the downside would be
Paul Dragoonis wrote:
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 un
> -Original Message-
> From: Paul Dragoonis [mailto:dragoo...@gmail.com]
> Sent: 18 August 2011 12:12
> To: PHP Internals List
> Subject: [PHP-DEV] Activation of IGBinary serialization
> extension in 5.4 by default
>
> Hey guys,
>
> After a brief dis
On Fri, Aug 19, 2011 at 2:47 PM, Arpad Ray wrote:
> On Fri, Aug 19, 2011 at 1:40 PM, Ferenc Kovacs wrote:
>> On Fri, Aug 19, 2011 at 2:31 PM, Arpad Ray wrote:
>>> On Fri, Aug 19, 2011 at 1:04 PM, Ferenc Kovacs wrote:
the downside would be that if you want to serialize/unserialize the
On Fri, Aug 19, 2011 at 1:40 PM, Ferenc Kovacs wrote:
> On Fri, Aug 19, 2011 at 2:31 PM, Arpad Ray wrote:
>> On Fri, Aug 19, 2011 at 1:04 PM, Ferenc Kovacs wrote:
>>> the downside would be that if you want to serialize/unserialize the
>>> data outside of php, your implementation should take care
On Fri, Aug 19, 2011 at 2:31 PM, Arpad Ray wrote:
> On Fri, Aug 19, 2011 at 1:04 PM, Ferenc Kovacs wrote:
>> 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 Ki
On Fri, Aug 19, 2011 at 1:04 PM, Ferenc Kovacs wrote:
> 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 seri
On 08/19/2011 01:15 PM, Jonathan Bond-Caron wrote:
> On Fri Aug 19 03:48 AM, Kingsquare.nl - Robin Speekenbrink wrote:
>>
>> 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 up
On Fri Aug 19 03:48 AM, Kingsquare.nl - Robin Speekenbrink wrote:
>
> 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?
>
100% against enabling it by def
All,
We're fairly heavy users of igbnary and we've found that the latest
1.1.1 from pecl has issues with values-by-reference and therefore can't
be used as a drop-in replacement for the standard serialiser as it
stands.
I suspect it's the same issue as this
https://github.com/igbinary/igbinary/is
Hi,
One pitfall I see is, that two separate system can communicate using
serialized data. They both must understand the same format and (in this
case) must be configured equal.
Regards,
Sebastian
2011/8/19 Kingsquare.nl - Robin Speekenbrink
> Dear All,
>
> Again with my 2cents into the basket:
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...
Als
hi Stas!
On Thu, Aug 18, 2011 at 7:27 PM, Stas Malyshev wrote:
>> . 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 (?!
Hi!
On 8/18/11 5:22 AM, Pierre Joye wrote:
. 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 fir
2011/8/18 Johannes Schlüter :
> On Thu, 2011-08-18 at 15:33 +0200, Ferenc Kovacs wrote:
>> we already do this (session.serialize_handler, defaults to our own
>> format, but can be set to wddx or igbinary)
>
> Well the session handler doesn't matter too much and is more of an admin
> thing, unlike s
On Thu, 2011-08-18 at 15:33 +0200, Ferenc Kovacs wrote:
> we already do this (session.serialize_handler, defaults to our own
> format, but can be set to wddx or igbinary)
Well the session handler doesn't matter too much and is more of an admin
thing, unlike serialize()/unserialize(). Those are the
2011/8/18 Johannes Schlüter :
> On Thu, 2011-08-18 at 12:48 +0100, Paul Dragoonis wrote:
>> 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 setti
Just add a check on what format is used on read, write with the new
format. Deprecate the old format in next version after 5.4 (or drop it
at all in 6.0 or whatever the new major version will be).
Make a noise about the change (I can do that for the Russian speaking
community with ease).
It will b
On Thu, 2011-08-18 at 12:48 +0100, Paul Dragoonis wrote:
> 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 f
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 addit
hi!
On Thu, Aug 18, 2011 at 1:12 PM, Paul Dragoonis wrote:
> After a brief discussion with Pierre I'm taking this discussion to here.
For the record here, I'm not in favor of bundling igbinary (or other
custom serializer). My main concerns are:
. the PHP serializer can be overridden at runtim
Hello everyone,
My first post after watching the list for a while: my opionion on this
would also be incorporate it into the core but with BC compatibility:
the serializer could (easily from what i understand) check to see if the
serialized format is in the `old` format and read that according
On Thu, Aug 18, 2011 at 12:38 PM, Roger Llopart Pla 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
>
>> Hi,
>>
>> On Thu, Aug 18, 2011 at 12:12 PM, Paul Dragoonis
>> wrote:
>> > Hey guys,
>> >
>> > Af
On Thu, Aug 18, 2011 at 1:30 PM, Arpad Ray wrote:
> Hi,
>
> On Thu, Aug 18, 2011 at 12:12 PM, Paul Dragoonis 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
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
> Hi,
>
> On Thu, Aug 18, 2011 at 12:12 PM, Paul Dragoonis
> wrote:
> > Hey guys,
> >
> > After a brief discussion with Pierre I'm taking this discussion to here.
> >
Hi,
On Thu, Aug 18, 2011 at 12:12 PM, Paul Dragoonis 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 performa
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().
29 matches
Mail list logo
