Right...so its broken, and it needs to be fixed. Moving away from a standards based protocol to something proprietary is a *really* bad idea.

Maybe if you want to make an *additional* connection method that can work between android and gtalk available that supposedly will be more efficient, that might be a good idea. But removing (or, I guess, moving away from) the ability to do standards compliant XMPP is the wrong direction.

Tieing android to the gtalk server smacks of a walled garden attitude. "Don't Be Evil" says that you should run, not walk, in the other direction.

On Feb 15, 7:58 pm, "Dan Morrill" <morr...@google.com> wrote:

Yes, and even the language used there indicates that this was a short- sighted way of going about it:

"The XMPPServer/GTalkService really *ONLY* has 2 goals:" (emphasis mine).

Clearly you all didn't think this one through to think about how powerful full XMPP capabilities, down in the core of the system, can be. This is an unusual situation, since Googlefolk are usually pretty well known for thinking through solution sets and how they can be more powerfully used and dramatically improve the state of the art. Unfortunately, you seem to have really dropped the ball on this one.

Except that the use of XMPP is not an implementation detail. Its a standards compliance issue, and its what really makes #1 and #2 so powerful. By killing XMPP (I realize that it wasn't really XMPP to begin with, but that's a bug to be fixed, thus issue 201 in the android issue tracker...that really should be re-opened), you've killed most of the power of the service.

Right, so you wanted to make it a walled garden. Not good, guys.

Remember, federation is all but completely invisible to the client, with a even halfway decent XMPP implementation for this (and you're building on Smack...most of the work is already done for you), the federation, and thus the further elimination of walled gardens comes along basically for free.

If XMPP isn't efficient enough for mobile uses (which I'm most certainly not convinced that claim is at all true), then consider adding an additional connection methed for the gtalk service from android...then you can sell the gtalk service as being more efficient (maybe), and that's fine, but sacrificing the openness of the platform on the alter of "mobile efficiency" should be embarrassing to you.

Yes, creation of a reusable XMPP Service with full support for the protocol is a great idea. But why Google is doing 95% (that's a WAG number) of the work and then flushing it down the toilet is totally beyond me.

Google really needs to rethink this. Its a *really* bad idea.