OK, here's my reply:
> Well, I'll try to elaborate on my rant. Most of it from memory (been a year ago since I last touched AMQP).
Back then when I looked at AMQP (and used it for one project):
AMQP is quite new - think about the early days of HTTP and XMPP. Some of the things you list have improved in the last year - but we have more work to do.
> * It was very hard to find reasonable documentation. The most accessible I found was the (excellent) http://blogs.digitar.com/jjww/2009/01/rabbits-and-warrens/ blog post. This was what eventually got us off the ground.
It's a very good post. I think the documentation at least as far as RabbitMQ goes has improved, see the link store here: http://www.rabbitmq.com/how.html and the del.icio.us repo that it links to, which is organised by tag.
We'd very much appreciate assistance in improving all this!
> Imho a testament to the shortcomings of the "official" documentation (where is it?).
The working group has not done a good job at putting out 'official' documents about AMQP, other than the specs, which do provide documentation. For some reason people choose to not read the specs, but I do recommend the 0-9-1 spec which is about 40 pages long (not too bad considering).
There will be more of a push to do 'official' AMQP docs this year.
> * RabbitMQ only implemented AMQP 0.8. I cannot remember the exact differences between 0.9 and 0.8 (and heck, good luck trying to find a document explaining them even today).
We do actually have such a doc but have not released it since almost everyone uses 0-8. The main point is that 0-8 and 0-9 are almost identical.
> For us it boiled down to some clients simply not working and it took a while to figure out what the problem even was.
This has all got better, there are hundreds of projects now that work with RabbitMQ: http://delicious.com/alexisrichardson/rabbitmq+usecase+clien...
> * Client interoperability was generally spotty, even in clients supposed to be compatible. It seems the idea of that whole spec-file stuff was to make the protocol pluggable and flexible. However the only thing it seems to have achieved is to make client development hell. The client we eventually went with (py-amqplib) doesn't even use the spec-file because "parsing takes too long".
Most people have a good experience with most clients. I am sorry you did not - did you try asking for help on the mailing list?
> * Moreover the sheer existence of http://www.rabbitmq.com/interoperability.html is a testament to a flawed protocol.
Er.. no. It's testament to our desire to be clear about semantics.
You mention STOMP - I assume you are aware that STOMP's semantics are underspecified so that interoperability is not possible without vendor agreement?
> If I can't rely on a 0.8 client to talk to a 0.8 server properly, then something is fundamentally wrong.
How long did it take for HTTP browsers to work with all web servers? Years and years - and most people only use a subset of HTTP.
> * There's a huge pile of semantic baggage (Exchanges, Bindings, Queues, Channels) that left us with a giant "WTF" the more we used it. Yes, it can be made work. But hell, talk about overengineering. Much simpler constructions could have been used to achieve the same goals.
There are a lot of messaging protocols, and none of them have managed to be complete, interoperable, open and simple. Please do help us to make RabbitMQ better, whether for AMQP or one of the other protocols it supports.
> * As I just learned during my googling for this post, apparently some of the problems have even been acknowledged by the officials and are supposed to be simplified in AMQP 1.0 (http://www.amqp.org/confluence/display/AMQP/Background+to+AM...).
Those comments refer to 0-10 which is a lot more complex.
> But I'm not expecting much, to be honest.
That's encouraging :-(
Why not? You can help with this stuff you know.
> So, that's just a few points that popped into my head immediately, there's more if I'd dig deeper. It's just a fundamentally bad protocol if I have ever seen one,
Thanks for taking the time to provide feedback. I'm not sure what to conclude from your specific comments. The interop stuff has been cleaned up in 0-9-1. The fact that people get confused by Exchanges vs Queues, and the programmable nature of AMQP, is being addressed in 1-0.
In any case, as far as RabbitMQ goes, it's a multiprotocol broker and so far we have learnt two things about using AMQP - (1) that it's a good core protocol for messaging, around which other gateways are easily provided; (2) yes the API could be simpler - we are working on that.
> and I'm honestly surprised to see people defend it even after the creators themselves (iMatix) acknowledge it to be a dead-end.
I think you are reading a lot into iMatix's public statements that may not be borne out by the facts. You may find this odd, for example: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2010-Ma...
> To put it from an different angle: When you think about what AMQP really does then how long would it take you to whip up a near-trivial but feature-equivalent protocol from scratch? I could think of many ways to skin that cat in a better way, with a simple, hackable, plain-text protocol.
I agree that plain text would be good, but it does not cut it for some cases. I'm a fan of plain text nonetheless. But if you think this is so easy, please get involved and help!
> You know, one of those protocols where I, as a developer, can even sniff and see what is going on at any time. Those are possible, as demonstrated by redis, memcached, STOMP, beanstalkd and many others.
I agree that plain text has some advantages, and am a huge fan of Redis, but don't see any of those as delivering a messaging protocol. This stuff is non-trivial unfortunately; as I say we'd welcome your input.
> I acknowledge that some complexity is unavoidable for advanced use-cases. Still, a good protocol layers the complexity in a way so that simple stuff remains simple and complex stuff becomes manageable. To me AMQP is a complete failure in both regards; you are confronted with the full complexity even for the most trivial use-case. And it seems for complex use-cases it adds a hefty layer of complexity of its own, rather than helping to wrap up.
I definitely agree that most users want a simple entry point.
Cheers,
alexis