4 ms·

Unfortunately, XMPP not a very good protocol. By virtue of its insane complexity, no client seems to quite interoperate with any other in anything beyond the mo

Unfortunately, XMPP not a very good protocol. By virtue of its insane complexity, no client seems to quite interoperate with any other in anything beyond the most basic features. Essential features that I have never managed to get working properly over XMPP include: * holding conversations with people who have intermittent network connections (mobile phone users) * sending/receiving files * multi user chat Ideal scenario would be that Google will solve these problems and release their new protocol with open specifications.

fakeer 14y ago
But it seems Google is done with opening up things. It's experimenting with closing and shutting things down.
- pekk 14y ago
  This is a really prejudiced statement. There are any number of things which are open like SPDY or V8. The closure of Google Reader (or Google Wave, etc.) may be annoying but it isn't a monopolistic power grab.
claudius 14y ago
> * holding conversations with people who have intermittent network connections (mobile phone users) I didn’t really try that, but it is usually the responsibility of the remote user’s server to check whether the user is online. Shouldn’t be a problem. > * sending/receiving files Works perfectly fine. > * multi user chat Works even finer than fine. What clients and servers did you use?
- cameronh90 14y ago
  Offline messaging is a problem in the sense that you would expect to be able to hold a reliable conversation with someone who is intermittently available rather than getting errors about the other person being unavailable, or messages being lost in the aether. If the person is actually offline, you should be able to rely on the other server to actually deliver the message when they get back. I don't think XMPP has very good systems for ensuring reliable message receipt at the protocol level. There are, I understand, draft standards (XEP-0198, XEP-0013) that would improve things but nothing implements it (at least consistently). File transfer: Clients I've used are Adium, Pidgin and Google Talk. What normally happens with file transfers is that either the person at the other end doesn't know I've tried to send a file, or if they do know, they click accept and the file never transfers, or if the file does transfer, my client somehow doesn't realise and the file transfer stays active forever. Usually there'll be a double-NAT in the way. The only time it does mostly work is GTalk to GTalk. Multi user chat: Is very confusing to set up, and while it is possible to get it working, in practise I've found nobody can figure out how to use it. It's sort of like the complexity of email multiplied by the complexity of IRC. This is unlike other chat protocols/clients where it's just a matter of inviting someone to your conversation. This isn't even getting into the other issues with the protocol, such as voice/video/sip/o-o-b stuff, the general efficiency of the protocol and it's applicability to mobile users (It's not great). I have set up corporate XMPP servers (ejabberd/openfire) before and am very aware of the difficulties of trying to get things to all work together. In the end people just end up opting for something [awful] like Microsoft Lync instead.

fakeer 14y ago

But it seems Google is done with opening up things. It's experimenting with closing and shutting things down.

pekk 14y ago
This is a really prejudiced statement. There are any number of things which are open like SPDY or V8. The closure of Google Reader (or Google Wave, etc.) may be annoying but it isn't a monopolistic power grab.

claudius 14y ago

> * holding conversations with people who have intermittent network connections (mobile phone users) I didn’t really try that, but it is usually the responsibility of the remote user’s server to check whether the user is online. Shouldn’t be a problem. > * sending/receiving files Works perfectly fine. > * multi user chat Works even finer than fine. What clients and servers did you use?

cameronh90 14y ago
Offline messaging is a problem in the sense that you would expect to be able to hold a reliable conversation with someone who is intermittently available rather than getting errors about the other person being unavailable, or messages being lost in the aether. If the person is actually offline, you should be able to rely on the other server to actually deliver the message when they get back. I don't think XMPP has very good systems for ensuring reliable message receipt at the protocol level. There are, I understand, draft standards (XEP-0198, XEP-0013) that would improve things but nothing implements it (at least consistently). File transfer: Clients I've used are Adium, Pidgin and Google Talk. What normally happens with file transfers is that either the person at the other end doesn't know I've tried to send a file, or if they do know, they click accept and the file never transfers, or if the file does transfer, my client somehow doesn't realise and the file transfer stays active forever. Usually there'll be a double-NAT in the way. The only time it does mostly work is GTalk to GTalk. Multi user chat: Is very confusing to set up, and while it is possible to get it working, in practise I've found nobody can figure out how to use it. It's sort of like the complexity of email multiplied by the complexity of IRC. This is unlike other chat protocols/clients where it's just a matter of inviting someone to your conversation. This isn't even getting into the other issues with the protocol, such as voice/video/sip/o-o-b stuff, the general efficiency of the protocol and it's applicability to mobile users (It's not great). I have set up corporate XMPP servers (ejabberd/openfire) before and am very aware of the difficulties of trying to get things to all work together. In the end people just end up opting for something [awful] like Microsoft Lync instead.