This might actually be slower than my current solution for hangouts, which is to open an empty circle in Google+. (If I open the Google+ home page, I see lots of social feed activity that a) I don't care about and b) takes a while to load.)
I'm often behind a slow public-wifi network and restricted on battery, so the amount of bandwidth and CPU used just to get me to text chat is actively a problem. I miss the XMPP days.
oh XMPP, you mean the protocol that required a TCP connection, and thus battery-draining maintaining a persistent connection ?
I was an XMPP enthusiast. Sadly, it never made the jump to mobile properly. I wish they had amended the standard to to add a session manager that would work well with mobile. Instead, last I check, everyone implemented their own hack. Google first, with Android GTalk. They used ProtoBufs [1]
Hey, did you know WhatsApp was based on XMPP? Yeah, good luck using that with an open client: their terms of service allows them to kick you off for using an unofficial client.
[1] I've come to think ProtoBufs would make a perfectly good transport for a hypothetical XMPP2. It's better packed, can be better framed, and as far as I've glanced allows the same extensibility as XML gave XMPP.
> oh XMPP, you mean the protocol that required a TCP connection, and thus battery-draining maintaining a persistent connection ?
I ran my XMPP client on a UNIX server, to which I connect using mosh. As it happens, I tend to have this mosh connection open all the time to do actual work, so there's no additional overhead from running an XMPP client remotely.
(Still, there's no particular reason that a persistent though quiet TCP connection needs to drain battery any more than any approach; a TCP connection can stay open indefinitely without traffic if nothing in between the applications decides to time it out.
There might be complications on actual mobile platforms like phones, if your platform's push notification system does abstraction-crossing magic with the cell networks, such that you can shut down your data connection entirely until it needs to be woken up. But my use case is a laptop, so a constant IP connection is assumed.)
I'm a geek too, but I think a time comes when we have to recognize that these kind of roundabout solutions, while fun and a testament to the flexibility of our systems, won't cut it if you want your protocol to take over the world (which the XMPP community was tongue-in-cheekily aiming for in the mid-00's).
And besides, I was trying to focus the discussion specifically on mobile, which is the major platform today.
I'm really disappointed with the new babel that has emerged in the mobile chat world.
Yes, that's absolutely fair. As a more general solution, you could build a very lightweight mobile app or website that used a server as a relay, and whose interface involved only minimal JS (enough to long-poll or similar) -- but only if you could implement the client part of the relay. XMPP would have been an obvious way to do that, but even a documented web protocol would work fine.
>oh XMPP, you mean the protocol that required a TCP connection, and thus battery-draining maintaining a persistent connection ?
Um, TCP connections are totally silent when idle, save for application level heartbeats. And how would you implement a protocol with push notifications without TCP?
It's true that mobile push services exist to save power - they do this by maintaining only one heartbeat, for the most part. But it's not a huge win, and it could be added to XMPP. I don't see how protobufs help this situation at all.
I'm often behind a slow public-wifi network and restricted on battery, so the amount of bandwidth and CPU used just to get me to text chat is actively a problem. I miss the XMPP days.