[Bug 24908] Communication policy (blocking policy) API

[bugzilla-daemon at freedesktop.org]

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

--- Comment #17 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-08-03 10:20:53 PDT ---
I suppose we can merge this if you insist, but since every deletion from the
middle of the enum breaks API, it seems sensible to get it into a somewhat
stable state first. The shortest path to a stable state, as is often the case,
is deleting everything that's new and controversial :-)

+          All contacts in the user's 'subscribe' or 'pending' contact
+          list can communicate with us. The associated variant is ignored.
+        </tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="Subscribe_Or_Pending_Or_Publish_List" value="7">
+        <tp:docstring>
+          All contacts in the user's 'subscribe' or 'pending' or
+          'publish' contact lists can communicate with us. The
+          associated variant is ignored.

There's no such list as 'pending'. There are subscribe, publish and stored
lists, each of which have (full) members, local-pending members and
remote-pending members; if you're keeping these, please be entirely clear about
what they mean.

In any case I'd be inclined to drop any of the "_Or_" versions that we don't
know a concrete use for; sorry I brought them up in the first place.

+          The associated variant is a list of contacts (signature 'au',
+          Contact_Handle[]) who can communicate with us.

"can't"? :-)

I don't think we should have Blacklist anyway, though, to reduce confusion with
contact blocking, Bug #28423 (or equivalently, the 'deny' list in the
pre-ContactList world), unless we really, really need it to be distinct. Do you
have a picture of how the two interfaces should interact?

(The difference between blacklist-based CommPolicy and contact blocking is that
contact blocking also prevents those contacts from seeing our presence, even if
they think they have a valid subscription to us - that's how blocking works on
at least Google Talk, and I suspect it works that way in basically every
protocol that has it.)

I think we should have a way to deal with the common case that all forms of
communication (channel types, here) are equal, and blocking one blocks them all
(XMPP privacy lists, as used in practice, do this). Perhaps an
immutable-after-CONNECTED flag on the Connection to say that that's how it
works, or the empty string as channel type, or something?

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