Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99655
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.17.20 as permitted sender)
To: Rasmus Schultz <rasmus@mindplay.dk>,
 PHP internals <internals@lists.php.net>
References: <CADqTB_hcMd8O0S9oT8QNUFuYnpscx0579Ofj59Vop=Q1YEj0eQ@mail.gmail.com>
Message-ID: <7b10b263-8090-62e7-bd9c-5e65e50dd85c@gmx.de>
Date: Wed, 28 Jun 2017 12:59:16 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <CADqTB_hcMd8O0S9oT8QNUFuYnpscx0579Ofj59Vop=Q1YEj0eQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: de-DE
Content-Transfer-Encoding: 7bit
Subject: Re: Binary (msgpack) serialize/unserialize
From: cmbecker69@gmx.de ("Christoph M. Becker")

On 28.06.2017 at 11:04, Rasmus Schultz wrote:

> 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". 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?

See also <http://news.php.net/php.internals/98834>.

-- 
Christoph M. Becker