[Standards] Using XMPP In A Mobile Environment

Ivan Vučica ivan at vucica.net
Fri Feb 13 18:50:28 UTC 2015

On Fri, Feb 13, 2015 at 3:33 PM, Florian Schmaus <flo at geekplace.eu> wrote:

> I'm not an iOS export, but I think I've heard that TCP connection are
> terminated anyway after something like 60 seconds (of inactivity?).

While I have not tested this, I would highly doubt this is the case for the
'VOIP' class of background applications, as this is exactly the use case.

> Anyway I would right now, not take iOS into consideration, because, as
> far as I know, you would need to use APNS anyway for XMPP push
> notifications.

I don't expect this statement to be correct either. You can trigger a local
notification from the background, which, as long as the app is running, is
functionally equivalent to a push notification.


Strictly speaking, your statement is currently true, precisely because
clients get killed by the OS. So indeed you need to use APNS for XMPP. But
this is due to not satisfying possibly overly conservative requirements
imposed by the OS. So the clients with the most enjoyable experience
typically open a connection from the developer's servers, and deliver
notifications over APNS. Should that continue to be true?

Right now, I'm trying to build a minimal set of required functionality.
> And this does include to bundle and defer stanzas that are by some
> mechanisms determined on the users server. But not the general deferring
> of all incoming stanzas

Don't misunderstand me, I'm highly appreciative of any efforts. I just feel
that iOS's very conservative backgrounding requirements could be satisfied
by (optionally) making the deferring more strict and conservative.

And I suspect other platforms might be happier as well.

My understanding of the difference is:
- you propose deferring /some/ stanzas (good by itself)
- I'd see use in, aside from deferring some stanzas, /all/ stanzas (even
the most urgent ones) should be coalesceable, to be delivered at most every
[client-determined value] seconds.

If we're discussing improving on ways to reduce or delay s2c traffic in a
mobile environment, we should seriously consider the needs of one of the
two largest mobile platforms. :-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20150213/c6639153/attachment.html>

More information about the Standards mailing list