Bug 28423

RequestBlockedContacts is no longer desirable to have: it has the same problems that RequestContactListAttributes did. It should be GetBlockedContacts.

Few thoughts on this:

Should BlockedContacts be a property instead of the method GetBlockedContacts() ?

Should the interface require implementing Conn.I.ContactList like Conn.I.ContactGroups does?

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

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

(In reply to comment #2)
> Few thoughts on this:
> 
> Should BlockedContacts be a property instead of the method GetBlockedContacts()
> ?

Probably not, because it can fail. I think it should have basically the same semantics as GetContactListAttributes in terms of when it can fail, and return the same error that GetContactListAttributes would.

> Should the interface require implementing Conn.I.ContactList like
> Conn.I.ContactGroups does?

Yes, I think so.

(In reply to comment #3)

> Probably not, because it can fail. I think it should have basically the same
> semantics as GetContactListAttributes in terms of when it can fail, and return
> the same error that GetContactListAttributes would.

Makes sense.

We need the ability to report a contact as abusive to server administrations when we block them.

Now with support for reporting abusive contacts:

http://git.collabora.co.uk/?p=user/danni/telepathy-spec.git;a=shortlog;h=refs/heads/blocking

http://people.freedesktop.org/~danni/telepathy-spec-blocking/spec/org.freedesktop.Telepathy.Connection.Interface.ContactBlocking.DRAFT.html

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

* Maybe the change notification should have a b: Abuse flag as well to indicate what happened?
* Less importnat, do we need a Protocols.Interface.Deny with some capabilities as well ?

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.

Looks good to me ;) go go go

Merged as final for 0.21.13, with some changes: RequestBlockedContacts now returns a{us} and BlockedContactsChanged now uses a{us} for both arguments. That is: rather than just throwing out handles, the CM also signals the contacts' identifiers.