Privacy Rewrite GSoC Project

[Sulabh Mahajan]

On Wed, Aug 5, 2009 at 2:38 PM, Mark Doliner <mark at kingant.net> wrote:

> On Wed, Aug 5, 2009 at 1:51 AM, Sulabh Mahajan<sulabh.dev at gmail.com>
> wrote:
> >
> > On Wed, Aug 5, 2009 at 12:58 PM, Felipe Contreras
> > <felipe.contreras at gmail.com> wrote:
> >>
> >> Not to mention that the differentiation would be a no-op in MSN as
> >> I've already explained.
> >>
> >> But I'll have to be clear on this: this new design is not solving
> >> anything and only introducing new problems. What is supposed to happen
> >> when you select "Allow all users" in MSN? There's no such privacy
> >> setting.
> >
> > "Allow all users" in MSN would be emptying the block list, including the
> > meta contact "all others". So it would be doing what it says, allowing
> > everyone.
>
> I don't think it's wise to empty the block list stored on the server.
> I think people expect that list to remain in tact, and if they use
> another IM client at another location they'll be confused/annoyed that
> they're block list is empty.  In this case my vote would be to not
> have an "allow all users" option for MSN.



Agreed.

What the objective is to provide a single interface for all the protocols,
faking a few features when needed (faked in the sense that we provide that
feature, but the official client doesn't), with minimum to no loss of any
features the native clients provide. That was the reason we wanted to do
away with allow/block list and all the privacy states AIM offers. Offer only
a few states like "allow all", "allow contacts in buddy list only", and let
rest of privacy handling be done through editing per contact settings. Core
picks those settings and decides what the actual privacy state is for the
prpl, and then makes it happen.
UI/user doesn't need to worry about the differences in the features offered
by the protocols.

I can do away with "allow all", since it causes loss of the privacy lists in
certain cases. But then how would we choose the allow all state for AIM,
without loss of privacy lists.

About providing separate privacy states for each protocol, which maps the
ones provided by prpl, do we want to do that?
Do we want to follow a single structure for each protocol, or do we want to
provide a different one for each?

We can follow a mid way path, provide or not provide "allow all" depending
upon the protocol, and keeping the rest the same.
But any changes beyond that to the provided states will make us shift from
our initial plan of "providing single interface for all the protocols".

Thanks,

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