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?

Thanks,

Chris


-----Original Message-----
From: [email protected] [mailto:[email protected]] 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

-----BEGIN PGP SIGNED MESSAGE-----
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 [email protected] has [email protected] in her contact list.
> 
> 1: [email protected] sends a probe to [email protected] 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 [email protected]'s client show that 
> [email protected] 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: [email protected] has 2 endpoints that have recently sent presence updates with 
> no type or show.  [email protected]'s client show's [email protected] as available.  
> [email protected] signs out one of his endpoints and that endpoint sends a 
> presence unavailable stanza.  One could assume [email protected] is still 
> available because his other endpoint has not sent a presence update.  
> However, it appears some clients will actually show [email protected] as offline 
> in this case.
> 

I would submit bugs against these clients.

> 3: [email protected] sends different statuses in presence stanzas from different 
> endpoints, how should [email protected]'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 [email protected]'s client 
> should behave in these cases?
> 

no comment (-:


- - m&m

Matthew A. Miller
<http://goo.gl/LK55L>

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

iQEcBAEBAgAGBQJP4SfvAAoJEJq6Ou0cgrSP118H/1po/kxEbC7KSLLJBd6scb6P
1kaBlQxnwctNJD6uDvODpBYxzHJPhtVajAggLM81KtEZ3V0oNPMEJDs1acW1nAa5
3+44HGMq3Zp7Ic3qx6bGARYNTNePaMeYmJ1brdBu5YbuxZeCU1nLWOEiVHPWYvQ0
czrx/XyI/8XBLmvhoFu1p9UHZMJsygtC6e1Kxo0Xiu/nyFlPuE/nSo5QEUF7ZvCK
nwHzS2A3UiMNuceydw6xHucYWzX1gmri1s/oQBr0Rp8/ecK+YrGq2xAUMnQNa9kC
pbbBjf8jxS/b7aqxjS3Yb6kVgQ3CZKWEjZi3mFelkLeg/jfrcHdO6ZDc5c0/JqM=
=vJdk
-----END PGP SIGNATURE-----
_______________________________________________
JDev mailing list
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: [email protected] 
_______________________________________________

_______________________________________________
JDev mailing list
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: [email protected]
_______________________________________________

Reply via email to