Shining example of another person who has failed to understand IRC (asynchronous messaging with spanning-tree delivery.)
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.
While I agree with you in principle that IRC is underrated, it is not a real messaging system as is.
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.
I often think of SMTP as well -- robust message queueing and routing with built-in failover, backoff algorithms, and myriad tools to view all the parts involved. An RFC822 message's envelope can contain infinite metadata and its body can contain text, json, xml, base64-encoded binary, you name it. You can encrypt messages with PGP, or secure the transport layer if you can determine who talks to you. There are more implementations that one can count, it works on every platform, and it doesn't scare away the systems guys.
I've also thought of SMTP as the ultimate queuing system. It really covers all of the bases for persistence, async delivery, bridges to every kind of network imaginable (think back to FidoNET, UUCP -- revive the bang path!), built in fault tolerance, etc.
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.
the guy behind RestMS is the same guy who designed and created AMPQ. I think that maybe it might be you who fails to understand, this isn't IRC buddy. That statement could be incorrect, but so what? At the end of the day this article proposes a standard that shows a way to create soft realtime webclient <-> server messaging that can handle all of the common problems this domain experiences. In all honesty, in my world the implications of this are ground breaking.
I don't see the reason for the "housecat", "parrot" and "wolfpack" patterns. These patterns have been around a long time in the EAI space, not sure in the logic in giving them a new name.
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.
Don't you think, maybe, thinking of a pack of wolves tearing away at a dead carcass, or a kitty coming to your outstretched hand, a flock of colourful macaw parrots flying in the Amazonian basin is more friendly than a dryly spoken PointToPointChannel, PublishSubscribeChannel and CompetingConsumers in camel case?
It is understandable that application programmers demand simplicity. As they need to implement these patterns, why not change the name?
More colourful, yes, but I couldn't see the reason behind the names immediately. "Dry" terms that actually happen to _describe_ their behaviour are immediately grasped and understood.
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.
maybe - but I found I could perfectly understand each pattern by relating the analogy of the fun colourful names to the behaviour of the problem. Well at least I can say it worked for me ;)
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.
Which goes into "Reverse Housecat", "Multimaster Housecat", "Wolf Call"... I can't say they are obvious at first glance.
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.
maybe A grade Technical Officers can grasp this technology easily, but actually there is a majority of B grade and C grade CTO. These are the guys who will set the trend of a technology. In other words it isnt the programmer who chooses the technology. This article is written for the B grade and C grade CTO to understand....
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.