| Thanks for your comment. I could not find the 139 page document to which you refer. There are two 0-91 docs, one is the spec definition for users, which as I said short and is mostly edge cases you can ignore. There is a second doc for implementers which defines the classes and methods in more detail. This is 63 pages long. Note also that for the purposes of client codegen, the BSD licensed XML file in 0-91 is only a few pages long - because the surface of the spec is surprisingly small. As a comparison, the definition of core XMPP (a Jabber server) in http://www.ietf.org/rfc/rfc3920.txt is 90 pages. BTW the core spec is just for IM not pubsub. In the case of both AMQP and XMPP the length comes from the requirement to interoperate between implementations. You make a good point about STOMP above. We love STOMP too. There is as you say a place for it - for lots of protocols. We have however found with STOMP that because many behaviours are completely unspecified, that it costs us a lot more to support (find and fix bugs, maintain stable behaviour under different conditions, etc). It is less likely that the same application talking to two STOMP brokers will behave the same way with both brokers - deterministically and predictably. Maybe this is a good thing - there is more scope for competing implementations? I don't think it's ideal. And let's not talk about JMS in this regard. I would not discourage people from writing their own brokers. You are among many who have done this and people will go on doing it. But although you may understand every line - what happens when someone else has to take over managing your code? What if the requirements change - or the scope of use grows? This is where products add value. A lot of our customers have extremely simple requirements like "don't ever lose my messages" or "broadcast to twenty different types of subscriber". So, I don't think it's fair to make generalisations about "complex requirements". I completely agree with you about RPC. Cheers, alexis |