[jdev] XMPP on Android, Round #2
treffer+jdev at measite.de
Tue Nov 2 14:08:44 CST 2010
On 11/01/2010 10:14 PM, Stephen Pendleton wrote:
> -----Original Message-----
> From: jdev-bounces at jabber.org [mailto:jdev-bounces at jabber.org] On Behalf Of Yann Leboulanger
> Sent: Monday, November 01, 2010 4:27 PM
> To: jdev at jabber.org
> Subject: Re: [jdev] XMPP on Android, Round #2
>> Couldn't Stream managment help for that?
> Yes, that would also be used in the cloud push scheme to resume the stream. The cloud push scheme allows it to work without having to establish a secondary XMPP polling connection. My feeling is that the approaches are practically the same but using Google's push would use the existing Android connection to the cloud service. Either way support for the asmack service to be notified of a wake-up-and-resume-session event would be needed.
But this would mean I'm doing a feature negotiation run to fetch the
queued stanzas, as XEP-0198 reserves throttling for servers:
"When a server acts as a receiving entity for an XML stream, it might
throttle the stream (i.e., impose rate limiting) if the initiating
entity (a client or a server) attempts to send too much traffic over the
stream (e.g., a very large number of stanzas, or a lesser number of
stanzas that are relatively large)."
So, if I get you right, I should kill the XMPP TCP connection to wait
for events on another idle TCP connection and then restart the XMPP
connection. Basically exchanging an idle secondary connection for a full
negotiation every now and then?
Could you please explain how this could save battery? Am I missing
> JDev mailing list
> Forum: http://www.jabberforum.org/forumdisplay.php?f=20
> Info: http://mail.jabber.org/mailman/listinfo/jdev
> Unsubscribe: JDev-unsubscribe at jabber.org
More information about the JDev