3 ms·

> That is a theoretically desirable technical property, but there is a strong argument to be made that extensibility, and the interoperability issues that resul

> That is a theoretically desirable technical property, but there is a strong argument to be made that extensibility, and the interoperability issues that result, is the Achilles heel of XMPP. > Of course, there is risk the other way around too: by over-specifying, you constrain your use cases, which may hurt adoption. IMO anything that doesn't have extensibility built in, will gain it after the fact whether you want it or not. Better to have clear deliniation of duties and a standards body than a hodge-podge of uninteroperable things.

jallmann 11y ago
> Better to have a standards body than a hodge-podge of uninteroperable things. XMPP has both in spades -- that's where the theory doesn't meet the reality. And XMPP is hardly alone; this is a chronic issue with messaging, because the problem space is so ill-defined. The most successful protocols have been extremely focused in scope. IPv4 is essentially unchanged from RFC 791. TCP has a very carefully curated set of options that has stayed small. For ~15 years, RFC 2616 was the only spec you needed for HTTP. Notice the layering here -- those protocols don't try to be everything for everyone, unlike XMPP's catch-all design.