Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99660
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain kelunik.com from 81.169.146.161 cause and error)
MIME-Version: 1.0
In-Reply-To: <CADqTB_hcMd8O0S9oT8QNUFuYnpscx0579Ofj59Vop=Q1YEj0eQ@mail.gmail.com>
References: <CADqTB_hcMd8O0S9oT8QNUFuYnpscx0579Ofj59Vop=Q1YEj0eQ@mail.gmail.com>
Date: Wed, 28 Jun 2017 19:41:40 +0200
Message-ID: <CANUQDChruDUhzOSf4H+r9-7SOwumueiKoZPQiFrXFkXAp5X9Rw@mail.gmail.com>
To: Rasmus Schultz <rasmus@mindplay.dk>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="001a113ce09a6271ab055308b2f2"
Subject: Re: [PHP-DEV] Binary (msgpack) serialize/unserialize
From: me@kelunik.com (Niklas Keller)

--001a113ce09a6271ab055308b2f2
Content-Type: text/plain; charset="UTF-8"

2017-06-28 11:04 GMT+02:00 Rasmus Schultz <rasmus@mindplay.dk>:

> Back in 2014 there was an informal proposal on the mailing list to replace
> PHP serialization with an efficient binary (msgpack) format.
>
> https://www.mail-archive.com/internals@lists.php.net/msg69870.html
>
> As argued back then, breaking serialize() and unserialize() is unacceptable
> for many reasons.
>
> Meanwhile, the default session-storage, third-party cache libraries, etc.
> continue to use serialize() and unserialize() with better options being
> available only outside of the standard PHP run-times.
>
> Why don't we either:
>
> 1. adopt msg_pack() and msg_unpack() from the PECL package as standard
> functions, or
>
> 2. add a new pair of functions, e.g. bin_serialize() and bin_unserialize()
> to supersede the existing functions
>
> Or possibly both - that is, alias the pack/unpack functions with names
> indicating they supersede the old un/serialize functions, but document the
> new bin_* functions are using "an unspecified internal format".


Uhm, why unspecified?


> This way,
> people can elect to use msgpack binary format now and in the future, or
> elect to use msgpack now and possibly a different format in the future.
>
> Optionally the bin_* functions could lead with a version byte (or maybe a
> 4-byte header) allowing backwards compatibility with future binary formats.
> This way we don't risk ending up in the same situation again in 10 years if
> we realize msgpack is bad for serialization for any reason.
>
> There are many other uses for a set of efficient (space and time)
> un/serialization functions, for example when packing small payloads
> (checksums, image dimensions, etc.) into URLs, when persisting data in
> cookies, etc.
>
> Thoughts?
>

You could also just gzip larger payloads, I guess that should give a good
reduction in size.

Regards, Niklas

--001a113ce09a6271ab055308b2f2--