[Bug 24908] Communication policy (blocking policy) API

[bugzilla-daemon at freedesktop.org]

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

--- Comment #4 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-07-12 05:58:39 PDT ---
(In reply to comment #2)
> Simon, what did you mean by aligning the access control model with rich
> presence? Is this another interface? Isn't rich presence broken up by feature?
> (Location, etc).

The way Location's access control works is that there's a property of type
Rich_Presence_Access_Control, which is a tagged union: a struct (uv) containing
a Rich_Presence_Access_Control_Type (an enum), plus a variant for extra info if
needed. There's also a property of type Rich_Presence_Access_Control_Type[]
listing the enum members that make sense in this implementation.

R_P_A_C is defined by SimplePresence, which doesn't use it itself. The idea is
that future Mood, Music, HatColour, etc. interfaces would each have a pair of
properties corresponding to the ones for Location. Avatars could also gain this
pattern if needed.

My idea was that communications policy could perhaps be controlled by a R_P_A_C
as well (the interpretation would be the same, but with "can see this rich
presence" replaced by "can communicate (in this way)", and we could add more
members to the enum if needed.

Communications blocking via the 'deny' list, or its replacement in the
ContactList world, should always take precedence, but this interface is about
what to do when people aren't blocked.

I have some proposals for extensions to Rich_Presence_Access_Control, from
earlier discussion; I'll follow up with those.

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