Hacker News Reader

Comment by sliderr | Hacker News Reader

"Hey this thing X is broken our new product solves all problems and is superior in any way."

While I too would like to see AMQP 1.0 rather sooner than later and despite the open standard there are only a few usable implementations, I doubt that this new and great wire protocol will solve all of AMQPs problems which are located in other areas.

View on HN

Here is a short critique of AMQP, it's dated but still accurate: http://www.imatix.com/articles:necessary-changes-in-amqp

We've waited 6 years for AMQP to develop a community and address basic issues such as its complexity and high cost of change. No progress... despite years (literally) of work to try to open the AMQP workgroup to wider participation.

We love the idea of open messaging protocols and invested a painfully huge amount in AMQP but it's not been worthwhile: almost as soon as we helped found the AMQP working group, the protocol was hijacked into something complex and untenable.

At iMatix we believe in simple, clean, fast software. Just run any AMQP broker and compare to 0MQ and the conclusion is clear: 0MQ wins, hands down.

0MQ still has a long way to go but it's totally open, and anyone with a good idea is welcome to contribute. No contracts to sign. Just join the mailing list and discuss.

We will make messaging patterns into 1st class citizens of the Internet.

Don't forget that Imatix has a long history of producing top notch infrastructure software. Their code is consistently, tight, fast, and pretty.

For anyone who wants to improve their C hacking, I highly recommend the SFL (Imatix's Standard Function Library): purtiest code you have ever seen.

Very kind of you. SFL is my work.

My honor :-)

Several times in my life I thought of sending an unsolicited resume to you guys, but always doubted I had what it takes.

I'm quite impressed, and many thanks for the documentation! All in all, a much more readable library than I've ever seen.

btw, did you know your documentation [1] has bad links for point_in_rec ? All links I've found link to mem_alloc.

http://legacy.imatix.com/html/sfl/

SFL saved my ass in the mid-1990s. I was in dire need of some easy-to-use, well-documented functionalities in C and SFL was easily the best there was. A million thanks for providing such high-quality code to the community!

Are you kidding? What is this: http://www.google.com/codesearch/p?hl=en#zAePDxanDsk/openamq...

You're looking at OpenAMQ, not SFL.

This is the metaprogramming we used to build OpenAMQ. It was very successful in technology terms (1M lines of real code generated from 20k lines of metacode) but a failure in social tems (too high a barrier to community participation).

That's a great link, thanks. I've just started reading http://sites.google.com/site/cinterfacesimplementations/, and it looks like SFL should provide a good companion piece at the very least. Great documentation.

It's not that imatix is some random company saying AMQP is broken... they are part creator of said beast. I think they've simply come to the conclusion that there is a better way to do it.

Pieter is the creator - I am pretty sure about this.

I designed and wrote AMQP versions 0.1 through 0.8 and iMatix founded the AMQP working group. I was editor of the last 0.9.1 spec which fixed almost all of the bugs and inconsistencies of 0.8. It's a great, clean, tight spec but still fundamentally flawed :-) As for AMQP/1.0, no comment, but I would not run my business on it.

Pieter, I recall you mentioning that there are three forms an industry can have as standard;

1) The best is a healthy number of implementations based on an open source specification;

2) The undesirable way is having a implemantations based on an API, namely JMS;

3) The lowest most undesirable way is having an implementation as industry standard, as this allows for vendor lockins, soaring prices, and tardy performance;

Having said that, ØMQ is an implementation (albeit fast and open) without an open specification , nevertheless, you are essentially basing your business on number 3. an implementation as industry standard (given that what you do, industry will follow). Secondly with your influential clout in this field, are you not pushing an implementation into the market as the next industry standard -> whereas it should ideally be an open spec?

Aside, what high performance (which excludes restms) substitute spec are you cooking up? Is there a slight possibility that you will reverse engineer the spec from ØMQ?

Nice question. 0MQ has a wire protocol but it's minimalist, just doing framing. As we push 0MQ out into wider use we'll grow the protocol stack upwards. It'll take years. We do have a protocol specification project - http://rfc.zeromq.org/

We do intend to deliver IETF-quality specs that turn messaging patterns like pubsub into 1st class citizens of the Internet, so that arbitrary vendors can produce pieces that plug into this. But these specs will still be really simple.

I've always advocated a standard API for AMQP and proposed one (WireAPI) years ago, because this reduces vendor capture. Imagine if vendors designed arbitrary socket APIs... well some do, and it locks their users in.

So 0MQ is partly an API standardization project, partly an architecture project (to build a layer that seems to be missing from the stack), and partly a protocol specification project.

I wish you strength and that the community support you! It looks like a decent direction to move in. Your efforts at messaging pattern commodification on the Internet looks especially interesting, given your experience with restms. I hope this cracks it and makes life easy for all of us!

Crikey, it really doesn't get much more simple than that! http://rfc.zeromq.org/

As for the wire protocol, there are two parts to it:

Simple framing is described here:

http://api.zeromq.org/zmq_tcp.html

Extension of the framing for multicast:

http://api.zeromq.org/zmq_pgm.html

Reply on news.ycombinator.com