4 ms·

> you don't want to prevent power-saving by keeping a TCP socket active Slight aside: keeping a TCP connection consomes almost nothing. In fact, that's how pus

by rakoo 5y ago

> you don't want to prevent power-saving by keeping a TCP socket active Slight aside: keeping a TCP connection consomes almost nothing. In fact, that's how push notifications work today on Android: a TCP connection is kept open, and apps' server send a ping to Google to tell the mobile to wake up. What prevents power-saving is if every app keeps a different socket open to a different server and pings the servers on different schedules. That forces the mobile to wake up constantly.

acdha 5y ago
Note that I said “active” — if you're getting things like presence updates, you'd want to filter them to allow the client to avoid keeping the radio active and that wasn't built in to XMPP. It's definitely not an excuse given Google's level of resources — they could have had a very optimized Google Talk client and published a spec for third-party clients to use the same notifications framework so I don't consider this more than a speed bump.
- zaik 5y ago
  This is already implemented in modern XMPP clients like Conversations. See https://xmpp.org/extensions/xep-0352.html https://xmpp.org/extensions/xep-0352.html
  - acdha 5y ago
    That's why I don't think it was more than a fig leaf for Google's true reasons for closing up their chat network. That was during the period where they were axing anything trying out-Facebook Facebook and I wouldn't trust the stated rationale for any of those decisions. It would be interesting to see whether Facebook/WhatsApp and iMessage have made them desperate enough to reverse course on XMPP but I'm skeptical that they'd be trusted enough to be successful.
    - Zash 5y ago
      In fact, Google already had a precursor to XEP-0352 called `google:queue`, but as I remember the stated reason for shutting down XMPP as being "spam"¹. Google apparently can't deal with spam in a federated communication system ... ¹ https://mail.jabber.org/pipermail/operators/2013-February/001571.html https://mail.jabber.org/pipermail/operators/2013-February/00... and then https://mail.jabber.org/pipermail/operators/2013-May/001680.html https://mail.jabber.org/pipermail/operators/2013-May/001680....
      - acdha 5y ago
        Yeah, it’s sad. I can get not peering with the world but it’s not like they couldn’t do something like an open CA-style agreement to follow certain standards as a condition to peering. If they’d done that, they’d be in a much better position to ask governments to require federation with an open protocol.

by rakoo 5y ago

acdha 5y ago

Note that I said “active” — if you're getting things like presence updates, you'd want to filter them to allow the client to avoid keeping the radio active and that wasn't built in to XMPP. It's definitely not an excuse given Google's level of resources — they could have had a very optimized Google Talk client and published a spec for third-party clients to use the same notifications framework so I don't consider this more than a speed bump.

zaik 5y ago
This is already implemented in modern XMPP clients like Conversations. See https://xmpp.org/extensions/xep-0352.html https://xmpp.org/extensions/xep-0352.html
- acdha 5y ago
  That's why I don't think it was more than a fig leaf for Google's true reasons for closing up their chat network. That was during the period where they were axing anything trying out-Facebook Facebook and I wouldn't trust the stated rationale for any of those decisions. It would be interesting to see whether Facebook/WhatsApp and iMessage have made them desperate enough to reverse course on XMPP but I'm skeptical that they'd be trusted enough to be successful.
  - Zash 5y ago
    In fact, Google already had a precursor to XEP-0352 called `google:queue`, but as I remember the stated reason for shutting down XMPP as being "spam"¹. Google apparently can't deal with spam in a federated communication system ... ¹ https://mail.jabber.org/pipermail/operators/2013-February/001571.html https://mail.jabber.org/pipermail/operators/2013-February/00... and then https://mail.jabber.org/pipermail/operators/2013-May/001680.html https://mail.jabber.org/pipermail/operators/2013-May/001680....
    - acdha 5y ago
      Yeah, it’s sad. I can get not peering with the world but it’s not like they couldn’t do something like an open CA-style agreement to follow certain standards as a condition to peering. If they’d done that, they’d be in a much better position to ask governments to require federation with an open protocol.