Hacker News Reader

Comment by tumult | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com