

Zed Shaw: The Petrichor Protocol Primitives - timf
http://petrichor-protocol.org/

======
swah
So this addresses problems with ZeroMQ?

~~~
spekoded
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. :(

~~~
shykes
For 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
I 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.

