> 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.
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.)