Privacy Rewrite GSoC Project

[Sulabh Mahajan]

Excellent input, appreciate it.


and a function to set the currently-active flags.  As alluded to above,
> my first idea for the former is to have prpl expose PurplePrivacyList
> objects with well-known names; maybe
>
>    enum {
>        /* Correspond to AIM, MSN, ...'s lists, plus the first and last
>         * of ICQ's lists
>         */
>        PURPLE_PRIVACY_LIST_ALLOW,
>        PURPLE_PRIVACY_LIST_DENY,
>        /* Correspond to ICQ's lists */
>        PURPLE_PRIVACY_LIST_INVISIBLE,
>        PURPLE_PRIVACY_LIST_BLOCK,
>        /* For Yahoo! */
>        PURPLE_PRIVACY_LIST_BYPASS_INVISIBLE,
>    };
>
> and the prpl exports only the lists it supports. They could have flags
> for things like "this list is only available when you're invisible",
> "this list is transient" (both of which only apply to Yahoo's magic
> invisible override list), "members of this list can't be on the roster",
> ...
>
> But thinking about this further... I think a better design would be to
> annotate buddies on the buddy list with their privacy state, and the
> prpl just exports a mapping from attribute type to the flags just
> discussed, indicating which attributes can be set and what they mean.
>

I understand the first design, in fact that was what I was about to follow
irrespective of what I mentioned in the initial proposal. I have a feeling
that this second design that you mentioned might be something, but I am
having little trouble understanding it. Could you please elaborate it a bit.
I didn't understand the mapping part altogether.

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.

A little explanation about your idea will be helpful.


>
> Telepathy's current approach corresponds more closely to the first
> approach I suggested. In fact, we represent the roster as several
> disparate lists: "stored" (everyone stored on your roster in any way),
> "subscribe" (those whose presence you can see), "publish" (those who can
> see your presence), then "allow" and "deny". We've never implemented
> "allow", and we've discovered in practice that splitting the roster up
> in to subscribe/publish/stored is never what the UI wants. I suspect the
> same would be true for libpurple: you want to see in the buddy tooltip
> whether they're blocked or whatever, so it makes sense for this
> information to be annotations on the blist rather than n separate lists.
>  (Maybe we could also unify "Has you: yes" and "Subscription: both", and
> make them machine-readable rather than localized strings? That'd be
> cool. Haze can't cleanly use these in their current form (because
> they're localized strings, and it would need to know what they actually
> mean in order to expose them correctly in the Telepathy API).)
>


"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.

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.


Thanks

Sulabh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/pipermail/devel/attachments/20090605/359caaef/attachment.html>