[Bug 28423] Conn.I.Blocking: replacement for the 'deny' ContactList channel

[bugzilla-daemon at freedesktop.org]

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

Will Thompson <will.thompson at collabora.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|http://git.collabora.co.uk/ |http://git.collabora.co.uk/
                   |?p=user/danni/telepathy-spe |?p=user/wjt/telepathy-spec-
                   |c.git;a=shortlog;h=refs/hea |wjt.git;a=shortlog;h=refs/h
                   |ds/blocking                 |eads/blocking
         AssignedTo|simon.mcvittie at collabora.co |telepathy-bugs at lists.freede
                   |.uk                         |sktop.org

--- Comment #8 from Will Thompson <will.thompson at collabora.co.uk> 2011-03-08 06:36:56 PST ---
I've pinched this from Danni!
http://people.freedesktop.org/~wjt/telepathy-spec-blocking/spec/Connection_Interface_Contact_Blocking.html

Review plz? I'm mostly just tidying and answering existing feedback from this
bug.

(In reply to comment #7)
> Some small nitpicks:
> 
> * I don't think BlockContacts ([12,3,4], True) should return NotCapable when
> you can't report abuse on
>    the protocol.
> 
> If a UI gets as far as to calling BlockContacts then it's basically to late to
> tell it this doesn't actually works (the user already clicked apply etc). The
> UI only has three options when this happens:
> 
> - It ignores the error, contact not actually blocked, bad
> - It throws an error in the users face, bad
> - handles the error by calling BlockContacts with abuse= False...
> 
> Assuming you can get this far, the last one is least bad way of handling it
> imho. So better to make that the normal behaviour; If the protocol doesn't
> support reporting abuse, the value of the abuse parameter is just ignored..

I agree.

> * Maybe the change notification should have a b: Abuse flag as well to indicate
> what happened?

I don't think this is necessary.

> * Less importnat, do we need a Protocols.Interface.Deny with some capabilities
> as well ?

Not sure this is particularly useful: you can tell whether ContactBlocking is
(possibly) supported using
<http://telepathy.freedesktop.org/spec/Protocol.html#Property:ConnectionInterfaces>.
If  we need to be able to discover whether reporting abuse is supported while
the connection's offline, we can add that later.

(In reply to comment #2)
> Should the interface require implementing Conn.I.ContactList like
> Conn.I.ContactGroups does?

I haven't changed this, but I think it makes conceptual sense to require it,
even if it's not strictly a prerequisite.

> (In reply to comment #0)
> 
> > * Do we care about protocols where you can look at the block list but not edit
> > it? My assumption is "no".
> 
> Do any such protocols exist? To my mind it's not useful to the client if it
> can't be edited anyway.

I agree.

> > * Do we support protocols/CMs where you can block people at runtime (or do
> > pseudo-blocking in the CM) but the changes aren't stored on the server? My
> > assumption is "no".
> 
> I agree, I don't think we want that. It's only going to be confusing to the
> user when her changes don't persist between connections.
> 
> If someone did want such a feature in their CM, they could always choose to
> implement the interface, and maintain their own blocked-list as a file on disk.

I agree and have added a remark to this effect in the introduction.

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