This reminds me that XMPP needs to make a comeback. Its push-oriented nature is efficient, was largely built in a time when we didn’t expect users to have unlimited data, and the eXtensible part has allowed it to modernize with multi-device encryption, loading chat history, etc.
It is a bit weird to frame one of two competing protocols as the successor of the other, when the only data point for this assertion is that one is older.
XMPP needs to die and stay dead. Its extensible design ended up being flexible in all the wrong ways, at once horrendously complex to implement and yet impossible to make do the right thing in several key areas.
You could make similar arguments against just about any mature network protocol (see the recent HN post about regrets in TCP/IP's design). Luckily we have plenty of choice, and there are bridges between the open solutions.
The fact is that XMPP has been, and still is, happily deployed at scale in various scenarios. You're welcome to your opinions, but they are just that.
Disclaimer: I'm a full-time XMPP developer and executive director of the XMPP Standards Foundation.
XMPP would be viable if it had a better iOS client. Some of my contacts switched to iOS and every app we tried wasn't as good as "Conversations" on Android.
As an alternative to web sockets and JavaScript, can I offer my alternative (ok, it's not persistent chat) implemented with character devices as a Linux kernel module? I don't know if it still works, but it has the same name :)
Personally, I'd not heard of k or kdb before so this was an interesting read.
The code is from 9 years ago, and looks to me like a proof of concept. It's a kinda stepping stone between the 90s approaches * mentioned in sibling comments and the bloat of the modern web.
* A truly amazing and dreadful time. The commercial (and artistic/indie) web pushed developers to twist immature technologies and create perverse superpowers. Never-closing responses in hidden iframes. Constantly exploiting JS engine bugs as features. Disgusting fun.
It's a somewhat esoteric, and extremely terse, language used by some financial modeling firms. Influenced heavily by APL, but (thankfully!) without the non-ASCII characters.
Lol. Seriously though, that's how all of these kinds of $DO_SOPHISTICATED_THING in $ABSURDLY_FEW lines goes.
The fact is that XMPP has been, and still is, happily deployed at scale in various scenarios. You're welcome to your opinions, but they are just that.
Disclaimer: I'm a full-time XMPP developer and executive director of the XMPP Standards Foundation.
https://github.com/brenns10/kchat
Personally, I'd not heard of k or kdb before so this was an interesting read.
The code is from 9 years ago, and looks to me like a proof of concept. It's a kinda stepping stone between the 90s approaches * mentioned in sibling comments and the bloat of the modern web.
* A truly amazing and dreadful time. The commercial (and artistic/indie) web pushed developers to twist immature technologies and create perverse superpowers. Never-closing responses in hidden iframes. Constantly exploiting JS engine bugs as features. Disgusting fun.
https://en.wikipedia.org/wiki/K_(programming_language)
Here's an open source implementation of k: https://codeberg.org/ngn/k/
kdb is a time-series database with deep integration to k. It is famously used in the financial industry.
q: slightly less-terse language written in k, with similar semantics. The vendor (kx) supports q, not k
kdb+: column-oriented database bundled with q
free for personal use for 12 months, then you click some buttons to renew another 12 months, etc https://kx.com/kdb-personal-edition-download/
https://azuremarketplace.microsoft.com/en-us/marketplace/app...
That's for commercial though.
One can get a personal use license for hobbies as other commenters have pointed out.
https://developer.apple.com/documentation/usernotifications/...
https://peter.hotgarba.ge