[jdev] Making sense of different presence info from different endpoints
linuxwolf at outer-planes.net
Wed Jun 20 01:31:27 UTC 2012
-----BEGIN PGP SIGNED MESSAGE-----
On Jun 19, 2012, at 18:03, Chris Eagan wrote:
> Is there any guidance or recommendation about how an XMPP client should show a contact's presence if it receives different presence information from different endpoints?
> Say alice at aaa.com has bob at bbb.com in her contact list.
> 1: alice at aaa.com sends a probe to bob at bbb.com and receives back presence from 2 different endpoints, each with the same priority - one has no show type and the other has show=dnd. Should alice at aaa.com's client show that bob at bbb.com is available (e.g. "green") or busy (e.g. "red")?
This is not official, and subjective to my personal views, but I would recommend using the following to determine which to display:
1) highest priority (treat a missing <priority/> as <priority>0</priority>)
2) timestamp, via jabber:x:delay or urn:xmpp:delay (treat a missing timestamp as timestamp==received time)
3) order parsed from the stream
I personally would not incorporate <show/> unless you want to get into a bikeshedding war with your users (-:
> 2: bob at bbb.com has 2 endpoints that have recently sent presence updates with no type or show. alice at aaa.com's client show's bob at bbb.com as available. bob at bbb.com signs out one of his endpoints and that endpoint sends a presence unavailable stanza. One could assume bob at bbb.com is still available because his other endpoint has not sent a presence update. However, it appears some clients will actually show bob at bbb.com as offline in this case.
I would submit bugs against these clients.
> 3: bob at bbb.com sends different statuses in presence stanzas from different endpoints, how should alice at aaa.com's client present this?
I personally would only display the information from the most "relevant" presence, using the ordering rules above.
> Is there any "official" or documented guidance on how alice at aaa.com's client should behave in these cases?
no comment (-:
- - m&m
Matthew A. Miller
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
-----END PGP SIGNATURE-----
More information about the JDev