[Bug 24908] Communication policy (blocking policy) API

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Wed Aug 4 14:21:36 CEST 2010


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

--- Comment #19 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-08-04 05:21:36 PDT ---
That's an interesting idea. Note that because the old 'deny' list exists,
TpBaseContactList supports blocking and unblocking contacts, and will have to
continue to do so in the medium term. TpBaseContactList is just a "view" - the
CM maintains the "model" - so a CM could easily have both TpBaseContactList and
some hypothetical TpBlockingMixin as views of the same information.

The access control models in RPAC come from XMPP PEP (asking the server to
control access to things it stores on our behalf), whereas blocking and
communication policy are XMPP privacy lists (asking the server to control what
messages will get to *us*).

SimplePresence is odd because its access control is implicitly the intersection
of the publish list (or equivalently, the publish attribute in Bug #21787) with
something else (by default, allow-all). In terms of RPAC, it looks like
(Publish_But_Not_Blacklist, [alice, bob]), except that that's too unwieldy a
format to actually use :-)

MSN might be an interesting real-world use case. As I understand it, you can
essentially set your access control to one of:

* my buddies (not sure whether this is Publish, Subscribe or some mixture)
* everyone

but there is also a blacklist, which takes precedence over either.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.



More information about the telepathy-bugs mailing list