[Bug 24908] Communication policy (blocking policy) API

[bugzilla-daemon at freedesktop.org]

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

--- Comment #21 from Eitan Isaacson <eitan.isaacson at collabora.co.uk> 2010-08-17 10:57:53 PDT ---
(In reply to comment #19)
> 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.

Yup.

> 
> 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*).

Privacy lists also control outgoing communication (<message-out/>,
<presence/>). Whether this is information that is stored on the server or
something the client sends directly seems like a protocol-specific detail.

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

In this proposed API it would look like this:
Conn.I.CommPolicy.SetPolicy("Conn.I.SimplePresence", (Blacklist, [alice, bob])

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

Maybe there needs to be a Everyone access control type as well...

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

Ugh. It looks like we will be re-inventing privacy lists before this is done..

I am beginning to think that maybe this API should not include presence at all,
but only communication. I originally thought we should unify all this under one
interface, but it is getting extremely complex. So maybe we need two interfaces
that are only complex (as opposed to extremely). I feel like if this were
limited to communication, it would be a lot easier to use.

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