4 ms·

Unifying the various communication channels would be a good thing, and very much in line with how Google has centralized identity and notifications behind G+.

by bergie 14y ago

Unifying the various communication channels would be a good thing, and very much in line with how Google has centralized identity and notifications behind G+. However, this part didn't sound so promising: Google’s recent decision to block non-native XMPP requests is the first step towards building their own closed communications platform.

cheald 14y ago
Google's been using a proprietary binary protocol in their XMPP payloads for a while now, IIRC.
cameronh90 14y ago
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.
notaddicted 14y ago
It would be supremely amusing if Google takes this step towards babelizing[1] web chat under the banner "Babble". EDIT: although from a Google-centric point of view it is kind of the opposite, since they are unifying. [1] The narrative of the city of Babel is recorded in Genesis 11:1-9. Everyone on earth spoke the same language. As people migrated from the east, they settled in the land of Shinar. People there sought to make bricks and build a city and a tower with its top in the sky, to make a name for themselves, so that they not be scattered over the world. God came down to look at the city and tower, and remarked that as one people with one language, nothing that they sought would be out of their reach. God went down and confounded their speech, so that they could not understand each other, and scattered them over the face of the earth, and they stopped building the city. Thus the city was called Babel. [from http://en.wikipedia.org/wiki/Tower_of_Babel http://en.wikipedia.org/wiki/Tower_of_Babel]

by bergie 14y ago

cheald 14y ago

Google's been using a proprietary binary protocol in their XMPP payloads for a while now, IIRC.

cameronh90 14y ago

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.

notaddicted 14y ago

It would be supremely amusing if Google takes this step towards babelizing[1] web chat under the banner "Babble". EDIT: although from a Google-centric point of view it is kind of the opposite, since they are unifying. [1] The narrative of the city of Babel is recorded in Genesis 11:1-9. Everyone on earth spoke the same language. As people migrated from the east, they settled in the land of Shinar. People there sought to make bricks and build a city and a tower with its top in the sky, to make a name for themselves, so that they not be scattered over the world. God came down to look at the city and tower, and remarked that as one people with one language, nothing that they sought would be out of their reach. God went down and confounded their speech, so that they could not understand each other, and scattered them over the face of the earth, and they stopped building the city. Thus the city was called Babel. [from http://en.wikipedia.org/wiki/Tower_of_Babel http://en.wikipedia.org/wiki/Tower_of_Babel]