Simple class import like Javascript?

[msgpack]

Simple class import like Javascript?

[laruence]

I am afraid that it's a hard work, lots php codes need to be wrote

[tucson-tom]

I stumbled onto this project. I was wondering the same thing but realized that a few issues will arise: Floating point conversions will be annoying and any PHP-based userland solution will be at least 100 times slower than a native implementation. Performance will suffer because, for whatever reason, PHP has a hard time with parsing strings one character at a time in userland.

However, I can see where the request comes from because it is fairly standard behavior for a PHP developer who makes an extension to also make a userland function/class-based solution that attempts to use the extension but falls back to the userland function/class implementation if the extension is not available using the same names as those found in the extension. This allows applications to use the library and not fail to operate because the extension isn't installed. The PHP core developers do this already through PEAR.

Within PHP, I still think JSON is the better solution. The primary concern of MessagePack's homepage seems to be bloat in JSON. Throwing gzip at JSON is going to be more effective and the compression will be comparable - actually MessagePack will likely fare worse as is frequently seen with various binary serialization formats when they are compressed (the lead byte or bytes tend to cause dictionaries to reset more frequently). As far as binary data goes, Base64 is sufficient for most needs (33% bloat factor) but if a programmer is bundling binary data in serialized storage, they are probably doing it wrong.

PHP also has serialize() and unserialize(), which handles all of PHP's constructs natively. If the app is entirely PHP, there is little reason to not use those built-in and well-maintained functions. You're better off trying to optimize those functions for improved performance than implement an extension.

So, as a storage format, MessagePack isn't really better, and I'd argue worse, than JSON. And for a pure PHP app, possibly worse off than serialize()/unserialize(). Performance is really the only potential significant benefit, which is precisely what the various organizations on the MessagePack homepage are using it for but is not your homepage's focus. Of course, if performance is the only real benefit, this request for a "simple class" in PHP which performs 100 to 1,000 times slower than the extension doesn't actually make any sense. I like the idea of MessagePack for PHP on some level, but PHP already has powerful serialization functionality built-in that has had the bugs hammered out, including several buffer overflow security vulnerabilities.

I don't know how good of a programmer you are, but if my choice is to vet a third-party PHP extension vs. use the built-in stuff that has been vetted repeatedly against a massive test suite, I'm generally choosing the latter. But let's say I would vet your software, I also evaluate how well the sentence structure is of the programmer on public forums. "I am afraid that it's a hard work" says either "English is a second language" or "lazy bum" to me and I approach the project with trepidation knowing that I will have to do a full vetting cycle vs. something a little more casual. Having a well-written PHP function/class would go a long way to validating your status as a programmer to be trusted to run server-level code in the PHP core and would make vetting the extension itself a lot easier for those who have to vet your code before allowing it into real production environments.

I know some of what I said is a bit harsh, but PHP is the 800 lb. web server scripting language gorilla in the room. You can get all the Ruby, Python, and C enthusiasts on board just about any bandwagon and it'll feel good, but PHP has to be targeted differently.

[rybakit]

For the record, I've just released msgpack.php, a pure PHP implementation of the MessagePack serialization format. And the performance is not as bad as one may think.