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.
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.
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.
> * 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.
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.
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]
I can only assume that Babble is a code name, Google Babble would be a horrible brand name. It looks off, it sounds off and it has negative connotations.
It's not Google Chat in web interface. It's just chat, a noun, not a service name (like mail compares to GMail). At least in my interface, and Google confirms. [1]
Also, I wasn't presumptuous, it was just an innocent remark.
I wanted to prove you wrong so I went to Google.com/talk but sure enough, you were correct. Even the title of the html document[1][2] says <title>Google Chat - Chat with family and friends</title>
I was not trying to be presumptuous. I really believed you were wrong. GChat just sounds wrong to me. However, something sounding wrong to me has never stopped it from being true.
Apparently Google endorses Google Talk and resists the GTalk name. I guess it's easier to be found when your page title is Google Chat even when the service is called Google Talk (did you notice Google Chat is not anywhere but the page title?)
Once Google is the nexus for the greater part of the world's communications, the project could be renamed Google Babel. We can then prepare allegations of hubris, and the possibility of them exploiting it for sinister purposes.
"The shadow of that hyddeous strength / sax myle and more it is of length."
I tend to agree 'Babble' has bad connotations for serious uses. But, we might have said the same thing about 'Twitter' or 'Yammer' or 'Hangouts'. There's a definite trend of words with slight/playful/unserious undertones proving useful as brands that still manage to appeal in serious situations.
There was a 'go' language before Google's Go. There were products named 'iPhone' before the Apple iPhone. If the prior use is obscure enough, and you can afford the legal/buyout costs, a name collision isn't necessarily fatal.
Jabber/XMPP and CalDAV support are two of the best things that Google has going for it. If support for both of those are going away, that is not a good sign.
I agree that interoperability with open standards is very important, but your first statement is beyond hyperbolic. Do you really think support for XMPP and CalDAV are the company's most valuable assets?
While I hope they aim a little lower this time and work out the UI first, it'd be a true shame if they didn't attempt some resurrection of the agent/plugin interaction they attempted with Wave.
I'm all for Google fixing their mess of communications platforms, but by attempting to consolidate those into a proprietary solution, I fear they've doomed it to the same fate as Google Wave.
If they were to at least include support for XMPP clients, they would be golden; however, the opposite appears to be true.
After they captured a good chunk of the RSS eyeballs, then pissed off the users, I'm wary of anything Google does. I'm going to have to spend a significant amount of time decoupling myself from their existing services.
I think Google is not much concerned about the crowd which loves to brew its own coffee(HN and the elk) and curate their Ghostery/ABP prefs, but they are rather focussed on the majority which loves to buy things online and also click on ads and hardly care how much Google reads their email.
There is nothing wrong with XMPP, but it is an instant messaging and presence protocol. Google started adding point to point video and audio calls which is a hack that doesn't work well when you want to incorporate video/audio conference, route calls to the PSTN (E.164) dialing, provide calling features (transfer, call forwarding, call waiting, find me / follow me). That is why there is SIP. Google has acquired SIP providers and I understand that their Hangouts backend supports SIP, so I do think they were going to introduce this capability to their environment, but I hope that they are going to stick to an industry standard here as it allows people to choose the endpoint that best meets their need. Time will tell...
I think this may have less to do with the fulfillment of a long term Google+ type social strategy and more of a reaction to the explosive growth of communication apps like WhatsApp, Wechat, and Line. These apps have grown to critical mass and can use their positions to grow into full blow threats to anyone with significant market share in social.
But the point I was trying to make is that if they say not enough people are using it that means it's not financially viable to keep operating (see: Google Reader).
I'm not looking forward to the day I have to open up gmail to chat with people. Using Adium to collect all of my chat under one place is absolutely essential to my daily workflow.
46 comments
[ 410 ms ] story [ 2500 ms ] threadHowever, 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.
* 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.
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?
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.
[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]
EDIT: I was being presumptuous about presumption, so, presumptive comment removed. Presume.
Also, I wasn't presumptuous, it was just an innocent remark.
[1] http://www.betabeat.com/2012/02/10/google-says-gchat-is-not-...
I was not trying to be presumptuous. I really believed you were wrong. GChat just sounds wrong to me. However, something sounding wrong to me has never stopped it from being true.
[1]: https://www.google.com/talk/
[2]: http://i.imgur.com/ceHnRcA.png
Apparently Google endorses Google Talk and resists the GTalk name. I guess it's easier to be found when your page title is Google Chat even when the service is called Google Talk (did you notice Google Chat is not anywhere but the page title?)
"The shadow of that hyddeous strength / sax myle and more it is of length."
Not entirely related to Google's idea, but not completely unrelated either.
I also came across a chat system for the Plone CMS. [2]
[1] http://sourceforge.net/projects/babble-chat/
[2] http://babblechat.org/en/latest/
If they were to at least include support for XMPP clients, they would be golden; however, the opposite appears to be true.
I think Google is not much concerned about the crowd which loves to brew its own coffee(HN and the elk) and curate their Ghostery/ABP prefs, but they are rather focussed on the majority which loves to buy things online and also click on ads and hardly care how much Google reads their email.
But the point I was trying to make is that if they say not enough people are using it that means it's not financially viable to keep operating (see: Google Reader).
Yeah. And then MSFT shuttered it for Skype a little bit ago.
Ads: not actually a magical miracle money tube.
That doesn't mean "put ads in product" automagically converts to "sustainable profit/loss".