[Bug 38603] Incorrectly reports offline contacts as unknown if presence arrives before the roster
bugzilla-daemon at freedesktop.org
bugzilla-daemon at freedesktop.org
Thu Jun 23 18:19:31 CEST 2011
https://bugs.freedesktop.org/show_bug.cgi?id=38603
Will Thompson <will.thompson at collabora.co.uk> changed:
What |Removed |Added
----------------------------------------------------------------------------
URL| |http://cgit.collabora.com/g
| |it/user/wjt/telepathy-gabbl
| |e-wjt.git/log/?h=fd.o-38603
| |-initial-contact-presence
Status Whiteboard| |fun with pronouns
Keywords| |patch
--- Comment #1 from Will Thompson <will.thompson at collabora.co.uk> 2011-06-23 09:19:30 PDT ---
Here's a fix. I'm not really all that happy with it.
As I say in one of the commit messages, I think it would be better if
GabblePresence represented peers' presences using the constructs available on
XMPP (available/unavailable/error, show={...} or null) rather than
GabblePresenceID, which adds a bunch of other states to muddy the waters (like
invisible, which makes no sense for peers, and unknown vs. offline). I looked
briefly into fixing this, but it's really invasive, not least because of the
self presence (on which invisible makes sense, and on which the presence ID may
be outside the range of GabblePresenceID to allow for plugin-supplied
presences…).
It occurs to me that there's an edge-case which this won't cover: if we get
<presence from='zie at foo.com'
type='unavailable'><status>baiii</status></presence> before we receive the
roster, Zie will be in the cache as unknown, and _maybe_remove() will not
discard that entry because Zee had a non-NULL message. So then Zie will
continue to be Unknown rather than Offline if the roster arrives and turns out
to have Zie on it. I checked RFC3921, and such presences are totally legal
<http://xmpp.org/rfcs/rfc3921.html#stanzas-presence-children> but I can't bring
myself to care that much.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.
More information about the telepathy-bugs
mailing list