On 11/2/10 2:08 PM, Rene Treffer wrote: > On 11/01/2010 10:14 PM, Stephen Pendleton wrote: >> >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf Of >> Yann Leboulanger >> Sent: Monday, November 01, 2010 4:27 PM >> To: [email protected] >> Subject: Re: [jdev] XMPP on Android, Round #2 >> >>> Couldn't Stream managment help for that? >>> http://xmpp.org/extensions/xep-0198.html >> 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)."
As far as I can see, there's no special reason to say that only servers can throttle. Something to test and discuss at FOSDEM... Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ JDev mailing list Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [email protected] _______________________________________________
