3 ms·

This is a myth (or one of those things that may have been true at one point but is now repeated as lore even though it was solved 15+ years ago); XMPP is actual

This is a myth (or one of those things that may have been true at one point but is now repeated as lore even though it was solved 15+ years ago); XMPP is actually pretty good on mobile. Between the persistent TLS connection which can let the radio go to sleep when no data is being sent (without the tail time of creating a new TCP connection constantly) and TLS style stream management it's very battery efficient when you're using a server that's optimized for mobile.

krageon 8y ago
The last time I looked into this (maybe 6 months ago), this could only be achieved using non-standard/experimental server extensions with absolutely no guarantee of stability. This then led me to believe that it was one of those things that was theoretically possible, but not practically possible. Has that changed in the meantime?
- arendtio 8y ago
  Well, experimental doesn't mean it isn't usable (we are talking about an experimental standard here, not about experimental software). I run an ejabberd server and for example the Client State Indicator (XEP-0352), which is one of the extensions that improve battery life for mobile clients, was experimental for a long time but at the same time also available for major servers (e.g. community edition of ejabberd) and mobile clients like Conversations (open source too). So in my experience, the battery consumption of a modern XMPP client is quite good. When people are complaining about the bad mobile experience they are mostly referring to the time before the mobile extensions were built.
mst 8y ago
It was rather less than 15 years ago I had the conversations with gtalk architects (who liked XMPP and left when google abandoned interoperability) that led to my opinion. So apparently not everybody shares your definition of 'solved' - I appreciate the alternative opinion, but simply declaring it a myth is, I suspect, unlikely to convince remaining skeptics.
- ge0rg 8y ago
  I wouldn't subscribe to the "15 years ago" statement, but we have figured out mobile battery use pretty well, and the respective solutions are avialable in both server and client implementations. Have a look at [0] and [1] for (slightly biased but more detailed) elabortations. simply declaring it a myth is, I suspect, unlikely to convince remaining skeptics It's hard to provide specific counter-arguments to anecdotal evidence repeated since back when gtalk was a thing. [0] https://gultsch.de/xmpp_2016.html https://gultsch.de/xmpp_2016.html [1] https://wiki.xmpp.org/web/index.php?title=Myths#Myth_Three:_It.27s_too_bandwidth-inefficient_for_mobile https://wiki.xmpp.org/web/index.php?title=Myths#Myth_Three:_....
- SamWhited 8y ago
  The Google Talk people literally never tried to implement any of it as far as anyone could see publicly (eg. stream management, compression, client state indication, etc.). I'm not sure if it was a problem with discoverability, or if they just didn't want to, but their feedback was always that things they needed didn't exist, and then stony silence when someone would point out the thing they needed.

krageon 8y ago

The last time I looked into this (maybe 6 months ago), this could only be achieved using non-standard/experimental server extensions with absolutely no guarantee of stability. This then led me to believe that it was one of those things that was theoretically possible, but not practically possible. Has that changed in the meantime?

arendtio 8y ago
Well, experimental doesn't mean it isn't usable (we are talking about an experimental standard here, not about experimental software). I run an ejabberd server and for example the Client State Indicator (XEP-0352), which is one of the extensions that improve battery life for mobile clients, was experimental for a long time but at the same time also available for major servers (e.g. community edition of ejabberd) and mobile clients like Conversations (open source too). So in my experience, the battery consumption of a modern XMPP client is quite good. When people are complaining about the bad mobile experience they are mostly referring to the time before the mobile extensions were built.

mst 8y ago

It was rather less than 15 years ago I had the conversations with gtalk architects (who liked XMPP and left when google abandoned interoperability) that led to my opinion. So apparently not everybody shares your definition of 'solved' - I appreciate the alternative opinion, but simply declaring it a myth is, I suspect, unlikely to convince remaining skeptics.

ge0rg 8y ago
I wouldn't subscribe to the "15 years ago" statement, but we have figured out mobile battery use pretty well, and the respective solutions are avialable in both server and client implementations. Have a look at [0] and [1] for (slightly biased but more detailed) elabortations. simply declaring it a myth is, I suspect, unlikely to convince remaining skeptics It's hard to provide specific counter-arguments to anecdotal evidence repeated since back when gtalk was a thing. [0] https://gultsch.de/xmpp_2016.html https://gultsch.de/xmpp_2016.html [1] https://wiki.xmpp.org/web/index.php?title=Myths#Myth_Three:_It.27s_too_bandwidth-inefficient_for_mobile https://wiki.xmpp.org/web/index.php?title=Myths#Myth_Three:_....
SamWhited 8y ago
The Google Talk people literally never tried to implement any of it as far as anyone could see publicly (eg. stream management, compression, client state indication, etc.). I'm not sure if it was a problem with discoverability, or if they just didn't want to, but their feedback was always that things they needed didn't exist, and then stony silence when someone would point out the thing they needed.