If long lived - the battery effects are marginal. You are only getting presence of people who are subscribed to and the connection is open anyway. If you are paying by the byte (or SMS or pager message) for traffic that may be a different consideration since getting presence packets when you are not actively interested in that information may not be of much use and expensive
If using http polling and modulating your polling frequency based on whether inbound traffic is presence or message - you may wish to not speed up polling if inbound is just presence updates. This will save battery life.
Ofcourse - one level of indirection solves many problems - so you could develop a small proxy on the higher bandwidth side ( between your client and your xmpp server) which will maintain a cumultaive view of the roster and can then trickle out the presence changes on demand (pause/resume). This does not require a change in the protocol.
I am not sure if any of the XMPP servers implement a "refresh my roster" command or if the protocol demands it.
What would be interesting is the concept of a variable roster based on the resource you use to login - for example if you login with resource "/mobile", then your roster and subscriptions are only created for your contacts in the "Mobile Contacts" group ..you only appear visible to those contacts, and also only receive presence for contacts in those groups..
Stephen Pendleton <[EMAIL PROTECTED]> wrote:
There may be a small difference in battery savings, but since you still need
to keep an active data session going I doubt it is appreciable. I do not
think there is much of a difference between an active data session that is
transmitting and receiving application level data versus an active session
that is not.
I run a mobile XMPP client on mobiles all day long with EDGE/GPRS
connections and they are constantly sending and receiving location and
presence data and I haven't seen an issue as long as I charge the devices
every couple of days.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Tony Yat-Tung Cheung
Sent: Saturday, September 23, 2006 11:21 AM
To: jdev@jabber.org
Subject: [jdev] Suspending and resuming presence
I am a developer of a wireless Jabber client. I think the idea of
pausing/resuming presence information is an interesting one.
It is neat to block incoming presence information by using the
privacy list. To resume the incoming presence information, we will
have to do a presence probe on every roster. This is certainly not
ideal. There should be a way for us to retrieve the presence changes
(deltas) only. We may as well bring this idea to improve the XMPP
protocol?
Is there really a huge battery savings? Has anyone performed any
field testing of this idea?
Thanks.
Regards,
Tony Cheung
