[Bug 28423] Conn.I.Blocking: replacement for the 'deny' ContactList channel
bugzilla-daemon at freedesktop.org
bugzilla-daemon at freedesktop.org
Tue Mar 8 15:36:57 CET 2011
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.
More information about the telepathy-bugs
mailing list