RestMS
restms.org
restms.org
I like all of the wordings he has made up for things that have been around for 15+ years.
Making a good messaging system seems to be an unusually difficult problem. People have tried, over many years, and the results - as we just saw - seem to be all round mediocre. In my view the main reason we have not "solved" this domain (as we've solved operating systems, databases, file systems, word processors, spreadsheets, email, data representation, etc.) are that the problem has been too arcane to interest enough engineers.
I believe every statement in that paragraph to be incorrect.
First off, it is inherently synchronous, not asynchronous. On top of that does it lack a bunch of core features, namely persistence, and delivery/ordering guarantees.
The former can be worked around by implementing your actual pub/sub heavylifting in the form of irc-bots. But the latter is a killer that cannot be solved without significantly rearchitecting any existing ircd impl.
Disclaimer: Yes, been there, done that. ;-)
If you're interested in high performance messaging beyond AMQP then I suggest to take a look at the spread toolkit. It doesn't have persistence either but is pretty good otherwise.
The only thing really missing is delivery order guarantee. It isn't uncommon at all for a message to fail delivery, get stuffed into a retry bucket, and then a bunch of other messages get delivered without problem before the retry occurs. But even this is just an implementation issue. The underlying architecture is nearly perfect.
http://www.eaipatterns.com/ - http://www.eaipatterns.com/PointToPointChannel.html - http://www.eaipatterns.com/PublishSubscribeChannel.html - http://www.eaipatterns.com/CompetingConsumers.html
It also claims the "parrot" (publish-subscribe) pattern is the most widely used. In certain situations it is very common (Market Data, News, Master Data etc) - but these are fairly specific.
I understand that perhaps colourful and friendly names can be fun, but I suspect you'd have a hard time getting these accepted among the people that actually use the protocol.
I walked away from the AMPQ design specs, feeling a bit tense. Though I immediately grasped restms.org meaning. I think it is well written, describing the point accurately and in brevity. Once you clone the repo, there are more docs in there which are quite a good read - specifically the restms_developers.txt doc.
Metaphor is great for explaining things - and as a guide. Those names might make a great sidebar. I just don't see the need to rename things when it's a firmly established domain.