Privacy Rewrite GSoC Project

Will Thompson will at willthompson.co.uk
Mon Jun 8 04:40:02 EDT 2009


Sulabh Mahajan wrote:
> Here do you mean we should have a global list consisting of every
> contact from every account, including those not on the buddy list (like
> those who have been removed and blocked). Then associate various privacy
> states with each contact in the list. The prpls would then extract from
> these privacy states the lists they want according to the privacy
> features they support. Is that what you mean. Or we can have separate
> list for every account, derived from the servers through prpl or stored
> locally, and UI or privacy system will concatenate them to have a global
> list.

That summarizes my two (somewhat incoherent) suggestions well. I think
the one I prefer is:

* Expose the union of all contacts stored on the server as the purple
buddy list;
* Have attributes on buddies describing privacy states;
* Give those attributes well-known, unlocalized string keys (unlike MSN'
s _("Has you"): _("Yes") and XMPP's _("Subscription"): _("From (To
pending")) to leave it up to the UI how to display them.

I think the fact that on Yahoo!, you have to remove people from what the
protocol calls the contact list to block them, while on XMPP, you have
to have them on the roster to block them, is something prpls could hide
from the UI.

> "we've discovered in practice that splitting the roster up in to
> subscribe/publish/stored is never what the UI wants" --
> what is the reason for disliking the first approach, apart from the fact
> that the second approach better suits providing information about a
> contact in buddy tooltip. Is there any other reason for you to favor the
> second approach.

Well, if you want to display a contact list, you probably want to
include people who you're subscribed to, who are subscribed to you,
whether you have blocked them, etc. So the UI has to combine the n
different lists together, which is easy but tedious, and is silly when
the protocol representation is closer to what the UI wanted in the first
place, so the CM has done a bunch of (easy but tedious) work to split up
this information. :)

> With machine readable vs localized strings you mean representing the
> states with a list of objects with proper names in enum format, right?
> (or am I getting this wrong). Then UI can decide what string it wants to
> display for those types.

Exactly. See above re. the current _("Has you") annotation on MSN buddies.

Ethan, any thoughts?

Regards,
-- 
Will

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://pidgin.im/pipermail/devel/attachments/20090608/cd6b2746/attachment.sig>


More information about the Devel mailing list