Privacy Rewrite GSoC Project

[Will Thompson]

Sulabh Mahajan wrote:
> Hey guys,
> 
> So what method I have adopted is that, I am storing all the privacy
> information in the blist itself.
> Now we have a list of buddies and list of other contacts, with block
> message, block presence, and information being local only as flags to
> the buddy.
> 
> To store contacts not on the buddy list, we have a group specifically
> assigned, I have for the time being named this group _Privacy.
> I modified the code in blist.c so that public API remains the same, and
> buddies from _Privacy aren't referenced when we call functions like
> purple_find_buddy().

:'(

This sounds like a really bad idea to me. Any name you pick for a group
to hold these contacts is going to run the risk of clashing with a real
group name. Given that you're taking the path of storing these contacts
on the blist, the real issues would seem to be:

a. There's no way to store contacts who aren't in any group.
b. The UI can't decide for itself whether to display a buddy (based on
their subscription state, etc.) because there's no generic way to find out.

The first problem is a special case of the more general problem that the
buddy list's design, as a strict List -> Group -> Meta-contact -> Buddy
hierarchy, is basically wrong for most protocols. On XMPP, groups are
more like tags; I don't know of any protocol which forces you to have
contacts in exactly one group, so I'm going to stick my neck out and
suggest that the XMPP model is the right one. So rather than trying to
decide on a pseudo-group into which to put contacts to whom the user is
not subscribed, but has blocked or whatever, the correct solution would
be to fix the buddy list's design so that you don't have to.

Felipe touched on this: it's silly that one can and does have several
PurpleBuddy structs representing the same buddy on the same account.

In my mind, the contact list should basically be a set of contacts
annotated with the set of groups they're in, the directionality of
presence subscription (if any), whether they're blocked, etc etc. If
this were the case, the UI could say "aha, the user has no subscription
to this contact, and they're blocked; I won't bother to show them", and
then you wouldn't need to make blist methods skip certain contacts.

-- 
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/20090719/c3505c18/attachment.sig>