4 ms·

As you know, there's a lot of good in XMPP. The part that I think causes the most difficulty is that it's based on XML. I don't mean this in the typical knee-je

by Todd 11y ago

As you know, there's a lot of good in XMPP. The part that I think causes the most difficulty is that it's based on XML. I don't mean this in the typical knee-jerk XML bashing sense. It's just that XML is ill suited for a stream-based protocol. XML is amenable to extensibility, with its innate namespacing features. But this also made it difficult for beginners to use well and was easy to get wrong. The XML decision was really just a consequence of the times in which it was developed. It was a natural choice. If it were done again, it would be REST-based and use JSON as the data format.

tylorr 11y ago
Would it be worth it to try to replace XMPP with something very similar but using a JSON based protocol and clean up its worts in the process?
- Todd 11y ago
  I absolutely think it would be worth it. The data format change would be one thing. There are many other factors which are worth considering. For example, the long lived connections of XMPP don't work well in the mobile environment. There are XEPs which address things like this. I think to do it right, you have to build a company around it, and build it in the open. Also, no one is going to jump on a protocol just because it's open. It has to be built around a service which is compelling in its own right, and gains user traction regardless of the protocol. Geeks can get it going, but it has to be self sustaining.
- estefan 11y ago
  I'm using JSON for my new socketIO server. You can put anything on the wire with socketIO, so messages are small and simple. Plus the clients seem really good too. They'll auto reconnect, etc. if the server goes away. I haven't tested whether they'll queue messages while offline yet... guess I should. I'd definitely recommend it. This is a problem I've had multiple stabs at, but I finally feel like I've got a long-term solution now. But yeah, no federation, etc. My need is single-site realtime chat.
- rakoo 11y ago
  No. One of the problems of XML is that it's binary-intolerant, which means everything that isn't pure text is a second-class citizen. That means pictures, sounds, documents, compressed stuff and most importantly, any encryption. We've all agreed that encryption is now considered to be mandatory and must be included in a protocol right from the start, so any serialization that doesn't allow easy binary usage can't be used.

by Todd 11y ago

tylorr 11y ago

Would it be worth it to try to replace XMPP with something very similar but using a JSON based protocol and clean up its worts in the process?

Todd 11y ago
I absolutely think it would be worth it. The data format change would be one thing. There are many other factors which are worth considering. For example, the long lived connections of XMPP don't work well in the mobile environment. There are XEPs which address things like this. I think to do it right, you have to build a company around it, and build it in the open. Also, no one is going to jump on a protocol just because it's open. It has to be built around a service which is compelling in its own right, and gains user traction regardless of the protocol. Geeks can get it going, but it has to be self sustaining.
estefan 11y ago
I'm using JSON for my new socketIO server. You can put anything on the wire with socketIO, so messages are small and simple. Plus the clients seem really good too. They'll auto reconnect, etc. if the server goes away. I haven't tested whether they'll queue messages while offline yet... guess I should. I'd definitely recommend it. This is a problem I've had multiple stabs at, but I finally feel like I've got a long-term solution now. But yeah, no federation, etc. My need is single-site realtime chat.
rakoo 11y ago
No. One of the problems of XML is that it's binary-intolerant, which means everything that isn't pure text is a second-class citizen. That means pictures, sounds, documents, compressed stuff and most importantly, any encryption. We've all agreed that encryption is now considered to be mandatory and must be included in a protocol right from the start, so any serialization that doesn't allow easy binary usage can't be used.