Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99653
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain mindplay.dk from 209.85.192.173 cause and error)
MIME-Version: 1.0
Date: Wed, 28 Jun 2017 11:04:26 +0200
Message-ID: <CADqTB_hcMd8O0S9oT8QNUFuYnpscx0579Ofj59Vop=Q1YEj0eQ@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="f403045cd28e96be3b0553017814"
Subject: Binary (msgpack) serialize/unserialize
From: rasmus@mindplay.dk (Rasmus Schultz)

--f403045cd28e96be3b0553017814
Content-Type: text/plain; charset="UTF-8"

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?

--f403045cd28e96be3b0553017814--