4 ms·
"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 an
by sliderr 17y ago
"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.
- mahmud 17y agoDon'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.
- phintjens 17y agoVery kind of you. SFL is my work.
- mahmud 17y agoMy honor :-) Several times in my life I thought of sending an unsolicited resume to you guys, but always doubted I had what it takes.
- Groxx 17y agoI'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/ http://legacy.imatix.com/html/sfl/
- nicolas314 17y agoSFL 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!
- vier 17y agoAre you kidding? What is this: http://www.google.com/codesearch/p?hl=en#zAePDxanDsk/openamq/server/amq_exchange_headers.icl&q=openamq&d=1 http://www.google.com/codesearch/p?hl=en#zAePDxanDsk/openamq...
- phintjens 17y agoYou'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).
- mark_h 17y agoThat's a great link, thanks. I've just started reading http://sites.google.com/site/cinterfacesimplementations/ http://sites.google.com/site/cinterfacesimplementations/, and it looks like SFL should provide a good companion piece at the very least. Great documentation.
- lrm242 17y agoIt'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.
- setori88 17y agoPieter is the creator - I am pretty sure about this.
- phintjens 17y agoI 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.
- setori88 17y agoPieter, 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?
- phintjens 17y agoNice 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/ 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.
- phintjens 17y agoHere is a short critique of AMQP, it's dated but still accurate: http://www.imatix.com/articles:necessary-changes-in-amqp 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.