2017-06-28 11:04 GMT+02:00 Rasmus Schultz <ras...@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
