5 ms·
XMPP shares another feature in common with X.400: implementation complexity. Where XMPP had numerous implementation options and XML, X.400 has ASN.1. It's proba
by baobob 4y ago
XMPP shares another feature in common with X.400: implementation complexity. Where XMPP had numerous implementation options and XML, X.400 has ASN.1. It's probably straightforward to write another solid explanation that phrases SMTP's success entirely in terms of its simplicity
- mmmm2 4y agoAs an old sendmail hacker, it amuses me to see SMTP called simple. I suppose it is though, at it's most basic level. It's the extra layers added over the years (MIME, text encodings, security, ...) and sendmail itself that make it complicated. Email address routing used to be ugly too, but the consolidation on the <user>@<host> standard really helped there.
- jotm 4y agoI mean, it's in the name :P
- cryptonector 4y agoSMTP was simple then. It grew organically via grafting of new things. It's not simple now, but nothing would be.
- fulafel 4y agoEmail has grown without fragmentation, because interoperation is seen as a basic requirement by the users and operators. Also strictly speakng MIME and other content layer things aren't part of, and didn't need changes to, SMTP. This is of practical importance because it means email server infrastructure doesn't need to know about email content format evolution, only end user email software does.
- cryptonector 4y agoYes, this.
- deleted 4y ago[deleted]
- mjevans 4y agoI recall reading that XMPP also wasn't always fully implemented / federated between services. E.G. wasn't advertising basic client online / busy / etc janky between different siloed implementations?
- MattJ100 4y agoOnline/busy/etc. are part of the core standards and very basic functionality. All software has occasional bugs, but I never encountered widespread issues with statuses such as you seem to be describing. There was a period of time where if someone signed in using the Google+ chat client, they would appear online but wouldn't receive any messages you sent them from the XMPP side. That was entirely a Google implementation thing (they had stopped maintaining XMPP interoperability at that point).
- jcrawfordor 4y agoThe big growing pain for XMPP was behavior when you had multiple clients connected simultaneously. Extensions were added to the standard that unified behavior around which clients received messages (today we'd assume all of them but that was more up in the air at the time) and tracking of read status across clients in order to highlight new messages. But during perhaps the heyday of XMPP the extension was not universally supported by even some popular clients, so multi-client functionality could be confusing and inconsistent, e.g. messages delivered to only one client for no clear reason. This is a pretty well solved problem today but, well, no one is using XMPP.
- cryptonector 4y agoTooling is always an issue in the beginning, when you pick a new technology like XML or ASN.1. Tooling is not an issue now, but now is too late. Turns out that writing specs -and implementing them- around simple textual protocols is easier than building new binary and textual structured encodings.