[jdev] Making sense of different presence info from different endpoints

Chris Eagan cheagan at microsoft.com
Wed Jun 20 17:15:33 UTC 2012

Thanks for the responses!  Yes, I completely agree no attempts should be made to standardize UI.  Matthew, I agree with your specific suggestions to the examples.  I suppose what I meant was, is there any best practice on aggregating presence information?  (answer is, "no").  XMPP servers specifically do not attempt to aggregate presence so I was approaching it from the client perspective.  Do you think an best practices XEP about client aggregation of presence information would gain any traction/interest?



-----Original Message-----
From: jdev-bounces at jabber.org [mailto:jdev-bounces at jabber.org] On Behalf Of Matthew Miller
Sent: Tuesday, June 19, 2012 6:31 PM
To: Jabber/XMPP software development list
Subject: Re: [jdev] Making sense of different presence info from different endpoints

Hash: SHA1

On Jun 19, 2012, at 18:03, Chris Eagan wrote:

> Hi,
> 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?
> Examples:
> 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

Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

JDev mailing list
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: JDev-unsubscribe at jabber.org _______________________________________________

More information about the JDev mailing list