Privacy Rewrite GSoC Project

[Sulabh Mahajan]

On Mon, Jul 20, 2009 at 9:01 AM, Mark Doliner <mark at kingant.net> wrote:

> Other responses inline:
>
> On Sun, Jul 19, 2009 at 5:04 AM, Will Thompson<will at willthompson.co.uk>
> wrote:
> > Sulabh Mahajan wrote:
> >> 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.
>
> I agree with Ethan and Will here--we should not pick a "magic" group
> name like _Privacy.  If privacy info is going to be stored in
> blist.xml then there should be some flag or something that that
> specifies whether the group is visible.
>

As I said the name _Privacy, as well as using the name itself to mark it
magic is temporary. I am going to use flags to mark it hidden. Also will
change the name "_Privacy" to something that won't cause a collision. It can
be anything that wont cause a collision.

Also, we plan to change the way blist is stored to follow the XMPP model,
which means doing away with the hidden group, but that is going to happen
after this GSoC project. Right now I want to concentrate on the Privacy
Rewrite, and privacy subsystem should be mostly independent of how blist is
stored (sparing internals of a few functions).

But more importantly: I'm not sure I understand the reasoning for
> storing privacy info in the buddy list.  They seem like two logically
> different pieces of information.  Combining them seems to make things
> more complicated.  Could someone maybe explain the reasoning for this?
>

This was very well explained by Will in the initial discussions in this very
thread. The idea is to have only one list of all the contacts, and associate
these contacts with the privacy/subscription information. The reason for
storing privacy info in blist is that it is stored as information, and not
in the form of lists. A few flags for each buddy is all that we need, like
whether we receive messages from this buddy or not, whether we send presence
to this buddy or not, is this buddy on the server list or is local, and so
on. Constructing a separate list to store all this information (which is
just 3-4 flags), along with storing it locally, means a lot of unnecessary
work done by the UI and libpurple, it is inefficient and means a lot of
duplicate code.
Why not just tag some privacy information with the buddies we already store
in the list.

This would also help in generating tool tip information regarding privacy
for a particular buddy, and in computing the least restrictive state for a
contact which combines buddies from several accounts.

-- Sulabh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/pipermail/devel/attachments/20090722/4eec1ddb/attachment.html>