On Fri, Feb 13, 2015 at 3:33 PM, Florian Schmaus <[email protected]> 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. https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Introduction.html https://developer.apple.com/library/ios/documentation/UIKit/Reference/UIApplication_Class/index.html#//apple_ref/occ/instm/UIApplication/presentLocalNotificationNow : 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. :-)
