4 ms·
tl;dr: It's a poor man's Protocol Buffers, XDR, JSON, XML... It doesn't attempt to solve any of the problems 0MQ tries to solve. Heerreee we go! I'm surprised
by spekoded 15y ago
tl;dr: It's a poor man's Protocol Buffers, XDR, JSON, XML... It doesn't attempt to solve any of the problems 0MQ tries to solve.
Heerreee we go!
I'm surprised this ticked me off enough to post about it.
The only problem it tackles is one 0MQ intentionally and wisely avoided by delving into the data you're trying to send and dictating an encoding scheme.
Quoth the 0MQ Guide: "On the wire, ØMQ messages are blobs of any size from zero upwards, fitting in memory. You do your own serialization using Google Protocol Buffers, XDR, JSON, or whatever else your applications need to speak. It's wise to choose a data representation that is portable and fast, but you can make your own decisions about trade-offs."
Let's examine the claims made about this protocol's relation to 0MQ.
1. It's transparent and you can actually understand it.
Response: 0MQ isn't? There's ample documentation, the wire protocol is exceedingly simple and the code is right there.
2. It could be implemented in any language, not just C++.
Response: ... what? There are bindings for 0MQ for 20+ languages and there's nothing stopping you from implementing everything 0MQ offers from scratch in your favorite language. See Response#1.
3. It doesn't blow up your server with random asserts.
Response: Any external input that causes 0MQ to assert is considered a bug and will rightfully be tracked down and obliterated.
4. You can put it on the internet without worrying about it.
Response: see above -^
5. It can transmit actual data structures or raw binary data.
Response: Here's the similarity to 0MQ, we found it! They both use fancied up P-strings!
6. You can put it in an SSL socket or any other crypto protocol.
Response: True but you can do that with any serializing scheme.
7. It will work with any socket system, events, or threads.
Response: True but you can do that with any...
--
Between this and his PyCon presentation it seems like this "Zed Shaw" guy doesn't understand why 0MQ has caused such a stir. :(
- gaius 15y agoZed may have moved to Python, but he's still suffering from the parochical Ruby mentality that anything he didn't know about, didn't exist, and he's inventing it for the first time.
- shykes 15y agoThis seems quite unfair. Zed used 0mq to implement Mongrel2's network infrastructure. Whatever opinion he has on the subject is clearly informed by fact, not some stereotypical mentality.
- gaius 15y agoHe also has the Ruby habit of choosing a clever but not terribly meaningful name for everything.
- shykes 15y agoFor the record, at dotCloud we are big fans of 0mq but a lot of these comments are legitimate. The doc is not always clear or up-to-date, the code is extremely opaque to outsiders, and as a result a lot of the "20+" bindings are in fact wrappers around the reference C++ implementation - which is a problem for asynchronous runtimes such as NodeJS. This doesn't necessarily justify an incompatible fork - but seeing these issues addressed in such a dismissive fashion is a little worrying.
- spekoded 15y agoI can count the number of active projects that have absolutely up-to-date documentation on one hand. Opaque to outsiders who don't understand C++. What do you think "binding" means? This doesn't approach a fork. This is just a plea for a rewrite of 0MQ in Python with EXTRA BONUS FEATURES. Very much not the Unix way.