[Bug 19903] Implement the "stored" list

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Tue Jun 8 16:14:03 CEST 2010


https://bugs.freedesktop.org/show_bug.cgi?id=19903

--- Comment #4 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-06-08 07:14:03 PDT ---
(In reply to comment #1)
> The stored list should probably be a copy of the "subscribe" list on MSN.
> Because the official client only unsubscribes from the other side's presence
> when they are removed. It does not stop the other side from receiving our
> presence. So in TP terms, it removes from the subscribe list, but not the
> publish list.

Is this a protocol limitation (can't revoke permission to see our presence), or
an implementation detail of the WLM client?

> Otherwise you end up with the same state as maemo 5, whcih means that all
> deleted contacts show up in tp clients.

This is problematic for the current draft of Conn.I.ContactList (Bug #21787),
in which there is a "one big contact list" that is a superset of (perhaps
bigger than the union of!) the old stored, publish and subscribe lists. Every
contact outside that list may be assumed to have publish = No and subscribe =
No.

If we exclude people without "subscribe > No" from that list, then we're
basically lying - we're saying that other people aren't going to receive our
presence, 

In principle, the set of contacts to display is a UI decision: it should be
some filtered subset of the "one big list", either "subscribe > No" or the
union of "publish > No" and "subscribe > No".

However, it might be worth having some sort of boolean hint for "this contact
is potentially interesting", which UIs are expected to respect unless they have
a better idea; on XMPP, we'd set it on every contact with "publish > No" or
"subscribe > No", but on MSN, we'd only set it on contacts with "subscribe >
No".

-- 
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