[Bug 24908] Communication policy (blocking policy) API

[bugzilla-daemon at freedesktop.org]

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

--- Comment #18 from Eitan Isaacson <eitan.isaacson at collabora.co.uk> 2010-08-03 11:02:56 PDT ---
(In reply to comment #17)
> 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.
> 

So this is what I am slating for removal:
* Subscribe_Or_Pending_List: For the reasons you stated above, this is
confusing and has no concrete use case yet.
* Subscribe_Or_Pending_Or_Publish_List: ditto
* Subscribe_List: No concrete use-case yet.

Additions I think we should keep:
 * Blacklist: See below.
 * Closed: Seems useful.
 * Not_Understood: Weird XEP-0016 privacy lists are a good use case.

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

I'll fix that.

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

To reduce confusion, I think the scope of this interface (or Comm.I.Blocking)
should cover both. I don't think this should be spread out on more than one
iface. To include presence blocking, perhaps besides channel interfaces, we
should also support having Comm.I.SimplePresence (and other presence ifaces,
like Location) as keys in SupportedPolicies and ActivePolicies.

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

Maybe instead of having ifaces as keys (o), we should have iface lists (ao).
That way, if more than one communication method is grouped together (ie. for
the protocol the chat policy and call policy are synonymous, or if we include
presence, presence blocking and chat blocking are synonymous), we would
understand their relationship from the groupings in the SupportedPolicies and
ActivePolicies properties. For example:

SupportedPolicies = 
{['org.freedesktop.Telepathy.Channel.Interface.Text', 
  'org.freedesktop.Telepathy.Channel.Interface.Call'] :
 [Publish_List, Whitelist]}

^^ Text and Call are bound to each other and support Publish_List and Whitelist
policies.

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